- 1Server executes the tool and returns a `content` array (with optional `isError: true`)
- 2Host injects tool descriptions into the LLM's context
- 3Host sends `tools/call` with `name` and `arguments` to the server
- 4LLM decides to call a tool and emits a structured function call request
- 5Server returns an array of tool objects, each with `name`, `description`, and `inputSchema`
- 6Host sends `tools/list` to the server to discover available tools
MCP tool use is discovery-before-call: the host lists tools, injects their schemas into the model, the model picks one, then the host invokes it and returns the result.
Imagine walking into a workshop you've never seen. First you read the labels on every machine to learn what each does and which buttons it needs. That is the host asking the server for its tool list. Then you decide which machine fits your task, set its dials correctly, and press start. That is the model picking a tool and the host running it. The machine does its work and hands you the finished part, which is the server returning a result. You never press start before reading the labels, because you would not know what the machine expects. MCP enforces the same order: discover what exists and how to call it, then call it.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Ordering questions like this one look trivial until you notice the trap: candidates love to put the tool call near the top because that is the exciting part. But MCP enforces a strict discovery-before-call sequence, and getting the order right means understanding why each step depends on the one before it.
The whole flow exists to answer one question for the model: what tools exist, and how do I call them correctly? Until that question is answered, the model has nothing to invoke. So the protocol front-loads discovery, then lets the model decide, then handles invocation and result return.
This deep dive walks the six steps in order, names the messages on the wire, and explains the dependency that makes the order rigid. By the end you should be able to defend why no two steps can swap places.
The handshake comes before discovery
Every MCP session opens with a lifecycle handshake. The host sends an initialize request, the server replies with its capabilities, and the host confirms with an initialized notification. Capability negotiation here tells the host whether the server even offers tools, resources, or prompts, and at what protocol version. The two sides agree on a common version before any feature traffic flows.
This matters for ordering because discovery is conditional on the handshake. There is no point calling tools/list against a server that never declared a tools capability. The negotiation step is the gate that decides whether discovery is even worth attempting. If the server only advertises resources, the host knows not to ask for tools at all.
The handshake also establishes that the session is stateful. The connection is long-lived: the same channel carries the initialize exchange, every tools/list, and every later tools/call. That persistence is what lets later steps assume the catalog is already known, and it is why a server can push a list-changed notification mid-session rather than forcing the host to poll.
In interviews you do not always have to name the handshake explicitly. But knowing it sits before tools/list shows you understand that capabilities are agreed up front, not assumed, and that everything downstream rests on that negotiated contract.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Step | Message | Direction |
|---|---|---|
| Discover tools | tools/list | Host to server |
| Return catalog | Array with name, description, inputSchema | Server to host |
| Expose to model | Tool definitions injected into context | Host to model |
| Model selects | Structured function-call request | Model to host |
| Invoke tool | tools/call with name and arguments | Host to server |
| Return result | content array, optional isError true | Server to host |
Real products, models, and research that use this idea.
- Claude Code calls tools/list on each configured server at session start, then injects the discovered tools as Anthropic tool definitions.
- Cursor and Zed run the same discover-then-call loop over JSON-RPC, so any MCP server written once works across all three hosts.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does the host handle two servers that both advertise a tool named search?
Namespace or prefix tool names per server during injection; resolve collisions before the model sees the catalog so it picks unambiguously.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Putting the tool call before discovery. The model cannot invoke a tool whose name and argument schema it has never seen injected into context.
60 second bullets to scan on the way to the call.
Why discovery must happen before any tool call
What the initialize handshake establishes first
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.