The Third Umpire · 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 every server speaks the one protocol: grab its config snippet, drop it into your mcpServers, restart. The client then connects and discovers its tools exactly as it did for your scorecard — it does not care who wrote the server.

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.
      

      

        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.