The Video Assistant · Lesson 9 — The Transfer Market ← Course

The transfer market — servers you didn't build.

Most of the time you won't write a server at all — you'll sign one someone already published.

You just built and connected your own server. But in practice, most MCP servers you use are ones you did not write — ready-made, published by companies and the community, for files, Git, GitHub, Slack, web fetching, databases, and thousands more. Using them is how MCP earns its keep.

And it is the same three moves every time, because they all speak the one protocol: get the server's config snippet from its docs, paste it into your mcpServers (adding any token it asks for), and restart. The client connects and discovers its tools exactly as it did for your match-stats server — it does not care who wrote it.

before you sign anyone This is someone else's code, running on your behalf and seeing whatever you pass it. Add servers only from sources you trust, and give each one only the access it needs — a token with narrow scope, a folder rather than your whole disk.

Browse a few popular signings below — see how little it takes to bring each onto the field.

adding any server you didn't build — three moves
1Get its config snippet from the server's own docs or a trusted directory.
2Paste it into mcpServers — add a token or key if it needs one.
3Restart the client. It connects and discovers the tools — same handshake as ever.
tap a server to see how you'd add it
paste into your mcpServers
now you could ask

Sign the specialist. Skip the coaching.

You do not have to build a server to use one. Thousands are already published — you read what a server does, paste its snippet, hand it any key it needs, and restart. Because every server speaks the same protocol, the client connects and discovers its tools the same way, whoever wrote it.

That is the real reach of the standard socket: one afternoon you write your own tool; the next you drop in someone else's — files, GitHub, Slack, a database — with a few lines of config. Just remember each one is a door, so only sign from sources you trust.

Quick check
MCP is best described as…
Next: Lesson 10 →
Go deeper — where to find servers, and how to add them safely optional

Where to find them

The official example servers page lists the reference servers; the servers repository lists company-maintained “official integrations” and community servers. Many client apps also have a built-in directory you can browse — but that is just a convenient front-end for the same config.

Why the command is so short — npx and uvx

npx (Node) and uvx (Python) download and run a published package on demand, so npx -y @modelcontextprotocol/server-filesystem fetches and launches the server in one step. That is why most reference servers are a single command with a few args.

Secrets go in env, not in args

Servers that reach a private account need a key — a GitHub token, an API key. These belong in the env block (or the client's secret store), never hard-coded into a tool or pasted into a public place. Treat them like passwords.

Local package or hosted URL

Reference servers usually run locally via npx/uvx. A growing number of services instead offer a hosted server you reach by url and sign into — no local install, the vendor runs it. Same discovery once connected.

Scope the access

Give each server the least it needs: the filesystem server takes the folders it may touch as arguments, so point it at one project directory, not your home folder. A narrow token and a narrow path limit what a mistake — or a bad actor — can do.