How MCP, the Model Context Protocol, works inside an AI agent — tools that live on other companies' servers, reached by one MCP client with the same JSON-RPC messages (initialize, tools/list, tools/call) for every server, while the model sees them as ordinary tools, with the JSON of every request in the Anthropic Messages or OpenAI Chat Completions format.
MCP, the Model Context Protocol, is a standard way for an agent to use tools that live on someone else's server.
- An MCP server is a running program, listening for connections, that holds the real tools.
- The agent's MCP client is a mediator: each of its tools is a stand-in that forwards a call to the real tool
on its server and brings back the result.
- The servers are a fixed list in the agent's configuration, written by the agent's developer.
- A server publishes its tools: the client asks, with the same messages for every server.
- The model sees an MCP tool as any other tool, and still makes every decision.
- The agent, the loop and the context window are those of the
Simple Loop AI Agent
; this page moves the tools out to servers.
Reading the drawing
The user, the agent, the model and the wire are the Simple Loop AI Agent's; two things are new.
- The MCP servers, bottom left:
weather.example.com and calendar.example.com, two companies' programs,
each running and listening at its address.- Each lists the tools whose code it runs; the calendar server also shows the calendar they work on.
- The internet, or a company's internal network: the cloud every MCP message crosses.
- The MCP client, leftmost in the agent's tools, holds a stand-in for each tool the servers published.
add_reminder, beside it, is the agent's own function, the real tool itself.
The MCP messages
MCP is JSON-RPC 2.0 in HTTP requests, all to one address on each server, POST /mcp.
initialize: the server says what it offers (capabilities: here tools), the two sides agree on the
protocol's version, and the server hands back a session id (Mcp-Session-Id), which every later request
carries.tools/list: the server publishes its tools' definitions: a name, a description and an inputSchema.
The client makes a stand-in for each.tools/call: the client sends a tool's name and arguments; the server runs its code and answers with
content, a list of parts (text, here).
The first two run when the agent starts, before any prompt; tools/call runs whenever the model asks for an
MCP tool.
One client for every server
The messages are the same whoever wrote the server, so the agent's MCP client is one piece of code.
- The servers come from the agent's configuration, a file its developer writes (
mcp.json here), read when
the agent starts. The model takes no part in choosing them. - A new server is one more line in that configuration, with no new code.
- The tools stay fixed, as fixed as a function written into the agent: MCP makes plugging in someone else's
tools easy, but the developer still decides which.
- The server's author writes plain functions; the MCP SDK turns each into a definition, from its name,
docstring and parameter types.
- The model's side has no such standard: each provider has its own API. The top bar switches the requests to
the model between two of them, and the MCP messages stay the same.
What the model sees
To the model, an MCP tool is a tool: a name, a description and parameters in the request's tool list.
- The agent translates in both directions:
- a definition's
inputSchema becomes the API's input_schema (Anthropic) or parameters (OpenAI); - a
tools/call result's content becomes the tool result in messages[].
- The model decides which tool to call and when, exactly as with the agent's own functions.