The Third Umpire · Lesson 9 — The Team Sheet ← Course

The team sheet — how discovery works.

Two questions: where is the server, and what can it do? You answer the first; the server answers the second.

“Discovers” makes it sound like the client scans the network, hunting for a server. It never does. The client never searches. Discovery in MCP is really two separate questions — and each has a different answerer.

“Where is it?”
You answer, in the config. Either a launch command (a local server the client starts) or a URL (a server already running elsewhere). The client is told where; it does not go looking.
“What can it do?”
The server answers. Once connected, the client asks tools/list and the server sends back its tool definitions. This is the same whether the server is on your laptop or across the world.

That second step — asking a connected server what it offers — is the “discovery” MCP means. It is about capabilities, not location. A server on another machine is reached exactly the same way, except you hand the client a URL instead of a command.

Pick a local or a remote server, then step through it: you give the location, the client connects, and the roll call runs the same either way.

Step 1 of 4 · You give the location

You give the where. The server gives the what.

A client finds a server because you told it where — a command for a local one, a URL for a remote one. It never scans or guesses. Then, over whichever connection, it asks the server what tools it has, and the server answers. Location is yours to supply; capability is the server's to report.

That is why a server on another machine is no harder to use: swap the launch command for a URL, and the discovery — initialise, then tools/list — is byte-for-byte the same. One protocol, wherever the server lives.

Next: the transfer market →
▸ Go deeper — the handshake, and what “discovery” really covers optional

The initialize handshake

The first message on any connection is initialize: the client and server exchange protocol versions and capabilities, so each knows what the other supports. Only after this do they get to work. It is a version check, not a search.

Discovery covers more than tools

A server can offer three kinds of thing, and each has its own listing call: tools/list (functions to call), resources/list (data to read), and prompts/list (ready-made prompts). “Discovery” is really the client asking these questions and caching the answers.

Tools can change while connected

If a server's tools change, it can send a notifications/tools/list_changed message; the client then re-runs tools/list to refresh. So discovery is not strictly one-time — but it is always the client asking a server it is already connected to.

There is no network discovery in the protocol

MCP has no “find servers on my network” mechanism. If a client app shows a browsable marketplace or directory of servers, that is a feature of the app — under the hood it still just writes a command or URL into your config, then connects and asks tools/list.