How MCP Works: From User Request to Tool Result
A model does not directly control an MCP server. The host coordinates discovery, model reasoning, authorization, client requests, and the final response.
The clearest way to understand MCP is to follow one request. A customer asks a support agent: “Where is order 4812? If it is late, create a ticket.” Several components cooperate, and each has a different responsibility.
TL;DR
- The host connects to a server and learns which capabilities it supports.
- The client discovers tool definitions and their input schemas.
- The host selects which definitions the model may see.
- A model-proposed tool call is validated and authorized before execution.
- The result travels back through the host and becomes evidence for the final answer.
Step 1: connect and establish compatibility
The host creates an MCP client for the order server. The connection may use local standard input/output or a remote HTTP transport. The participants establish compatible protocol behavior and learn relevant capabilities before the host relies on optional features.
Capability information prevents assumptions. One server may expose tools and resources; another may expose only tools. The host should call only operations supported by that server and understood by the client.
Step 2: discover available tools
The client asks for the server’s tool list. The order server returns definitions such as get_order_status. A useful definition includes a stable name, a precise description, and a JSON Schema for inputs.
{
"name": "get_order_status",
"description": "Return shipping status for an order the current user may access.",
"inputSchema": {
"type": "object",
"properties": { "order_id": { "type": "string" } },
"required": ["order_id"]
}
}The host may cache definitions, refresh them when appropriate, and filter them before model use. Discovery is not authorization.
Step 3: the model proposes an operation
The host sends the user’s request and selected tool definitions to the model. The model produces a structured proposal: call get_order_status with order_id set to 4812.
This is the boundary many diagrams skip. Model output is untrusted input to the control plane. The host must verify that the tool exists, arguments match the schema, the user may access the order, and the request fits current policy.
Step 4: the client sends the MCP request
After authorization, the host routes the call through the client connected to the order server. MCP uses structured request and response messages so the client can correlate a result with the correct request.
The transport moves the message; it does not decide whether the action is allowed. Local and remote transports change deployment and authentication concerns, not the tool’s business meaning.
Step 5: the server performs domain work
The server validates the request again, uses an appropriately scoped downstream identity, calls the order API, and translates the response into structured MCP result content. If the API times out or denies access, the server should report that failure rather than inventing a status.
A read operation and a write operation deserve different controls. Reading order status may be automatic after authorization. Creating a support ticket may require explicit user confirmation because it changes an external system.
Step 6: the host turns the result into an answer
The client returns the result to the host. The host records the tool event and supplies the useful content to the model. The model can now answer: “Order 4812 is delayed by two days. Would you like me to create the ticket?”
If the user confirms, a second authorized call can invoke create_support_ticket. The host should preserve the confirmation and tool result in its audit trail.
Requests, responses, and notifications
| Message type | Expected behavior | Example |
|---|---|---|
| Request | Has an identifier and expects a response | List tools or call a tool |
| Response | Correlates to a request | Tool list, result, or error |
| Notification | Does not expect a response | A supported capability list changed |
The same pattern for resources
Tools are not the only path through MCP. A policy server can list readable resources, let the host select one by URI, and return its contents. The host may choose the resource deterministically because the current workflow requires it, rather than asking the model to choose an action.
Resource content still needs controls. The host should verify size and media type, select only relevant passages, preserve source identity, and treat embedded instructions as untrusted data. Reading context is usually less consequential than changing an external system, but it is not automatically harmless.
What happens when something fails?
A timeout may justify a bounded retry if the operation is safe and idempotent. Invalid arguments require correction. An authorization denial must not be reframed as a transient error. A state-changing call with an unknown outcome may require reconciliation before retrying.
The host should keep tool failures distinct from model failures. That separation improves debugging and prevents a fluent model response from hiding an unsuccessful action.
Builder checklist
- Keep a registry that maps every exposed tool name to one client connection.
- Validate schemas before routing a call and validate authorization separately.
- Record request IDs, server identity, duration, outcome, and user approval.
- Place explicit limits on result size and content types.
- Test timeouts, permission denials, invalid arguments, and ambiguous write outcomes.
Common mistakes
- Skipping discovery and assuming every server supports the same features.
- Letting a model proposal bypass host-side authorization.
- Retrying every error with the same policy.
- Sending raw server output into the model without size and content controls.
- Telling the user an action succeeded before receiving a confirmed result.
My Take
The host is the control plane. Any explanation that jumps directly from model to server hides the most important production responsibilities: selection, permission, consent, observability, and failure handling.
Knowledge check
- Why is tool discovery not the same as permission?
- Where should model-proposed arguments be validated?
- Why can retrying a write be dangerous?
Continue learning
Start with What Is MCP? if the roles are unfamiliar. Next, study MCP Architecture. For failure handling, read Handling Tool Failures in AI Agents.
