Model Context Protocol: How MCP Connects AI to Tools

Every time a new AI assistant wanted to read your files, query a database, or open a ticket, someone had to hand-build a custom connector for that exact pairing. The Model Context Protocol exists to kill that busywork. Introduced by Anthropic in late 2024 and now supported by hosts from Claude Desktop to Visual Studio Code, it is an open standard that lets any AI application talk to any external tool or data source through one common interface, the way USB-C lets a single port serve many devices.

If you build with large language models, this is the plumbing that increasingly sits underneath agent features. This guide walks through what the protocol is, the roles it defines, the two layers it runs on, then what actually happens on the wire when a model calls a tool. Everything here traces to the official MCP architecture documentation and Anthropic's launch announcement.

What the Model Context Protocol solves

The problem MCP targets is combinatorial. Imagine a set of AI applications on one side and a set of systems they want to reach on the other: your filesystem, a Postgres database, a GitHub account, a Sentry project. Without a shared standard, each application needs a separate, custom integration for each system. That is an M-times-N explosion of brittle connectors, every one carrying its own authentication and its own schema to maintain.

MCP collapses that into M-plus-N. A system exposes its capabilities once, as an MCP server, and any MCP-compatible host can consume it without bespoke code. As IBM frames it in its overview, the protocol standardizes tool discovery and execution so agents interact with external systems through declared schemas instead of one-off adapters. The documentation is explicit that MCP focuses solely on the protocol for context exchange; it does not dictate how an application uses its model or manages the context it receives. That narrow scope is deliberate, and it is why the standard has spread quickly across otherwise competing tools.

The three participant roles

MCP follows a client-server architecture, but with a specific twist worth getting right. There are three named participants, and the relationship between the first two trips people up.

• MCP host: the AI application itself, such as Claude Code or Visual Studio Code. The host coordinates everything and manages one or more clients.
• MCP client: a component the host instantiates to hold a single dedicated connection to one server. The client fetches context from that server on the host's behalf.
• MCP server: a program that serves context data, regardless of where it runs.

The key rule: the host creates one client per server. When Visual Studio Code connects to the Sentry server, its runtime spins up a client object for that link. When it then connects to a local filesystem server, it spins up a second, separate client. Each client maintains its own dedicated channel. So a host running four integrations is juggling four clients, each bonded to a single server.

A common confusion is that "server" implies something remote and heavyweight. It does not. The term refers to the program that provides context, wherever it lives. When Claude Desktop launches the reference filesystem server, that server runs locally on the same machine over standard input and output. The official Sentry server, by contrast, runs on Sentry's own platform and is reached over HTTP. Both are MCP servers; only their location and transport differ.

The two layers: data and transport

The protocol is organized into two layers, and understanding the split clarifies almost everything else. The data layer is the inner layer; the transport layer wraps around it.

The data layer defines the actual protocol: a JSON-RPC 2.0 exchange that specifies message structure and semantics. It covers lifecycle management, meaning the work of initializing a connection and negotiating capabilities, along with the server-side features that provide functionality and the client-side features that let a server ask things of the host. It also handles utility features such as notifications and progress tracking. This is the part most developers spend time on, because it is where the meaningful primitives live.

The transport layer handles how bytes move and how the connection is authenticated. It manages connection establishment and message framing, then abstracts those details away so the same JSON-RPC 2.0 message format works no matter how it is carried. MCP defines two transport mechanisms:

• Stdio transport: uses standard input and output streams for direct communication between processes on the same machine. There is no network overhead, which makes it the fast path for local servers.
• Streamable HTTP transport: uses HTTP POST for client-to-server messages, with optional Server-Sent Events for streaming. This is how remote servers are reached, and it supports standard HTTP authentication using bearer tokens or API keys passed in custom headers. The specification recommends OAuth for obtaining those tokens.

Because the transport is decoupled from the data layer, a server author writes against the same primitives whether the thing ships as a local stdio process or a hosted HTTP endpoint. That separation is part of why a single reference server can be deployed either way with little change.

Server primitives: tools, resources, and prompts

Primitives are the heart of MCP. They define what each side can offer the other. The documentation calls them the most important concept in the protocol, and there are three a server can expose.

• Tools: executable functions an AI application can invoke to perform actions, such as running a database query or writing a file. Each tool carries a name, a human-readable title, a description, plus a JSON Schema describing its inputs.
• Resources: data sources that supply contextual information, such as file contents or database records. These feed the model knowledge rather than triggering actions.
• Prompts: reusable templates that structure interactions, such as system prompts or few-shot examples.

Each primitive has associated methods for discovery and retrieval, plus execution where that applies. Clients call the listing methods to discover what is available before using anything. A client first asks for the tool catalog with tools/list, then invokes a specific entry with tools/call. That design lets listings be dynamic rather than hardcoded, which matters once servers start adding and removing capabilities at runtime. The documentation gives a tidy example: a database server might expose a tool for running queries, a resource holding the schema, plus a prompt with worked examples for using the tool well.

Client primitives: what flows back to the server

MCP is not one-directional. The protocol also defines primitives that clients can expose, which lets server authors build richer behavior without bundling a model SDK of their own. Three matter most.

• Sampling: a server can request a language model completion from the host using sampling/createMessage. This is the clever bit. A server author who wants model output can ask the host's model for it and stay completely model-independent, never shipping their own API key or provider library.
• Elicitation: a server can ask the user for more information or confirmation through elicitation/create, useful for gathering a missing parameter or getting sign-off before a sensitive action.
• Logging: a server can send log messages to the client for debugging and monitoring.

There is also an experimental cross-cutting primitive called Tasks, a durable execution wrapper that supports deferred result retrieval and status tracking for long-running work such as expensive computations or multi-step automation. It signals where the protocol is expanding: beyond single request-and-response toward workflows that outlive a single message.

A connection from handshake to tool call

Putting the pieces together, here is the actual lifecycle of an MCP session, drawn from the worked example in the official docs. It is a stateful protocol, so it opens with a negotiation rather than jumping straight to work.

First comes initialization. The client sends an initialize request carrying a protocol version (for example "2025-06-18") and the capabilities it supports. The server replies with its own protocol version and capability set, declaring which primitives it offers and whether it can emit change notifications. If the two cannot agree on a compatible version, the connection should be terminated. This handshake is also where identity and version info are exchanged for debugging. Once it succeeds, the client fires a notifications/initialized message to signal it is ready.

Next is discovery. The client sends tools/list with no parameters, and the server returns an array of tool objects, each describing its name, title, description, then its input schema. The host fetches tools from every connected server and merges them into a unified registry the model can draw on. That is how a single assistant can present a coherent menu of actions pulled from several independent servers at once.

Then comes execution. When the model decides to act, the host intercepts the call, routes it to the right server, and issues a tools/call request with the tool name and arguments. The server runs the function and returns a content array, which can hold text or richer formats, and the host feeds that result back into the conversation as fresh context. The example in the docs shows a weather tool returning a plain-text forecast that the model then folds into its reply.

Finally there are notifications. If a server declared that its tool list can change, it can later send notifications/tools/list_changed, a message with no id and no expected response, following JSON-RPC 2.0 notification semantics. On receipt, the client typically re-requests the tool list so the model always sees current capabilities. This event-driven refresh is what keeps dynamic environments in sync without the client polling on a timer.

How MCP compares with the old integration model

It helps to contrast MCP with what came before. The earliest wave of model tool use leaned on proprietary function-calling formats, where each vendor defined its own JSON shape for declaring functions and the developer wrote provider-specific glue to match. That worked inside a single ecosystem but did not travel. A function wired for one assistant had to be rebuilt for the next, and a tool provider wanting broad reach had to court each AI vendor separately.

MCP reframes the relationship. Instead of the application owning every integration, the capability lives in a server that any compliant host can discover at runtime. The schema-first design means a host does not need to know in advance what a server offers; it asks, receives a typed catalog, and exposes those entries to the model. As Anthropic argued at launch, that turns integrations into a shared, reusable layer rather than a private cost each product pays again and again. The reference SDKs in several languages, plus the public servers repository, give developers a running start instead of a blank file.

One subtle payoff of the schema-first approach is portability across model providers. Because a server declares its tools through plain JSON Schema rather than a vendor-specific function format, the same server works whether the host is driving a Claude model, an open-weights model, or anything else that speaks the protocol through its host. The model never sees MCP directly; it sees a normalized tool registry the host assembles. That indirection is what lets the ecosystem grow without every participant agreeing on a single underlying model, and it is a big reason adoption spread beyond the company that proposed the standard.

Security and trust considerations

A standard that lets models invoke real actions raises real stakes, and MCP's design reflects that. Because tools can run code and touch live systems, hosts generally gate execution behind user awareness, and the elicitation primitive exists precisely so a server can pause to confirm a sensitive step rather than acting silently. On the transport side, the recommendation to use OAuth for remote servers pushes authentication toward scoped, revocable tokens instead of long-lived secrets baked into config files.

None of that removes the need for judgment. A malicious or compromised server could describe a tool deceptively, and a host that blindly trusts every catalog entry inherits that risk. The practical guidance is to treat third-party servers the way you would treat any dependency: prefer reference or well-maintained implementations, inspect what a server exposes with a utility such as the MCP Inspector before connecting it to an agent, and keep the model's available actions scoped to what a given task actually requires. The protocol gives you the structure to do this; it does not make the trust decisions for you.

The hosts and servers shipping today

The standard is not theoretical. On the host side, mainstream AI applications already act as MCP hosts, including Anthropic's Claude Desktop and Claude Code as well as Visual Studio Code, which lets a coding session reach external systems without leaving the editor. Each of these reads a configuration file that lists the servers it should connect to, then handles the handshake and routing on the developer's behalf.

On the server side, the public reference repository ships ready-made implementations for common needs, from a filesystem server that exposes local files to connectors for issue trackers and observability platforms such as Sentry. Vendors have started publishing their own official servers too, which is the clearest signal that the protocol has moved past the experimental phase: a tool provider now has an incentive to ship one MCP server rather than maintain a separate plugin for every assistant. For a developer evaluating the space, the fastest orientation is to install a reference server, point a host at it, and watch the discovery handshake populate the model's tool menu in real time. That single exercise makes the abstract roles concrete faster than any diagram.

Why a shared standard changes the trajectory

The significance of MCP is less about any single feature and more about coordination. Before it, every AI vendor and every tool provider was quietly negotiating private integrations, and the result was a thin, fragmented layer of capability that did not transfer between products. An open protocol with named roles, a versioned handshake, plus a fixed set of primitives turns that into an ecosystem where one well-built server is instantly useful to many hosts.

The pieces still maturing, such as the experimental Tasks primitive and the steady refinement of the authentication story around Streamable HTTP, point at where the work is heading: longer-running, more autonomous agent workflows that need durable state and trustworthy auth. For anyone designing AI features today, the practical move is to treat MCP as the default integration surface rather than reaching for a custom connector, and to lean on the reference servers and SDKs rather than reimplementing JSON-RPC by hand. If you want a sense of how model capability and these connective standards are evolving together, the wider coverage on our blog tracks both sides of that story.