Tool use & MCP
How is the Model Context Protocol built?
MCP has three roles: a host (the AI application), a client inside it, and a server that exposes tools, resources, and prompts. The pieces talk over JSON-RPC, and the standard now spans OpenAI and Google.
Under the hood, MCP has three roles: a host (the AI application), a client inside the host, and a server that exposes capabilities. The host does not talk to a server directly — it creates one client per server, and each client holds a dedicated connection to its own server. An application connected to three separate MCP servers is running three separate clients internally, even though only one host process is visible to you.[1]
A server can offer three kinds of thing, called primitives: tools the model can call to take an action, resources it can read for context, and prompts it can reuse as interaction templates.[1] Clients can offer primitives back to servers too — the most useful is sampling, where a server asks the client’s own model for a completion, so a server author can lean on whatever model the host is already running instead of shipping one.[1]
The pieces talk over JSON-RPC 2.0, split into two layers. The data layer defines the message format itself: connection setup, capability negotiation, and the primitives above. The transport layer carries those messages — either stdio, for a server running as a local process on your machine, or streamable HTTP, for a server running remotely and shared across many clients.[1] A connection starts with an initialize handshake where client and server each declare what they support, so neither side calls a method the other cannot handle. From there, most exchanges are simple: tools/list to discover what is available, tools/call to run one. When a server’s tools change mid-session, it can push a notifications/tools/list_changed message rather than wait to be asked, which is how MCP stays synchronized without the client polling.[1]
By 2026 the standard had spread well beyond its origin, with OpenAI and Google supporting it and a large ecosystem of public servers. That adoption is what turns MCP from a nice idea into a default — see why MCP exists for the integration problem it replaced, and authorization for how the transport layer secures a remote connection.
References
- Model Context Protocol — Architecture — Model Context Protocol