MCP is an open protocol for connecting an agent to external tools and data over a standard client-server interface, so a tool integration is written once instead of once per agent. The client/server/host shape, stdio against HTTP/SSE transports, what a "tool" and a "resource" mean in MCP terms, and why one server definition working across many clients matters most once you run more than one agent.
what MCP is
The Model Context Protocol, MCP, is an open specification for how an AI agent talks to external tools and data sources. Anthropic published the first version of it and open sourced the spec and reference implementations; it is now maintained in the open, with clients and servers shipped by many vendors who are not Anthropic. The protocol itself is transport-and-message-format detail, not a product.
The problem it answers is ordinary integration math. Say there are N agent applications, Claude Code, an IDE plugin, a chat client, and so on, and M tools each of them might want to reach, a database, a ticket tracker, a filesystem, a search API. Without a shared protocol, connecting all of them is N times M pieces of bespoke glue code, each with its own auth handling, its own way of describing what the tool does, and its own bugs. MCP proposes a single interface both sides implement once: a tool builds one server, an agent builder writes one client, and any combination of the two works without either side knowing about the other in advance.
host, client, server
Three words get used loosely in casual writing about MCP. The spec is precise about them, and the precision matters once you are debugging a connection.
A host can hold many clients open at once, one per server it is connected to, but each client only ever talks to the one server it was created for. That one-to-one rule is what keeps a compromised or misbehaving server's blast radius contained to its own connection rather than able to reach across into another server's session.
A server, in turn, is usually thin. It does not reimplement the thing it exposes; it wraps something that already exists; a REST API, a database driver, the local filesystem, a CLI tool, and translates MCP requests into calls against that underlying system. Writing an MCP server for an existing API is normally a matter of describing the API's operations in MCP's terms, not rebuilding the API.
stdio vs HTTP, and when each fits
MCP defines the message format, JSON-RPC 2.0, and leaves the transport open. Two transports cover almost every real deployment.
stdio: the server is a local subprocess
The host launches the server as a child process and the two talk over its standard input and output streams, one JSON-RPC message per line. There is no network involved, no port to open, no TLS to configure. This is the natural fit for a server that only ever needs to run on the same machine as the host: a filesystem server, a local git server, a wrapper around a CLI tool already installed. A typical host config for one looks like this:
{
"mcpServers": {
"git": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-git", "--repository", "."]
}
}
}HTTP with Server-Sent Events: the server is remote or shared
The alternative is a server reachable over HTTP, with a persistent Server-Sent Events stream carrying the server-to-client messages. This is what a server needs once it is not local to any one host: a company-run server that many people's editors connect to, a SaaS product exposing its own API as MCP, or anything that needs to keep running when no host happens to be open. It costs more to stand up. You now need authentication over the wire, a process that stays listening, and reconnection handling for a stream that can drop.
tools, resources, and prompts
A server exposes capabilities to a client under three primitive types. The distinction between them is about who decides when the model sees something, not about what kind of data is involved.
- Tools are named, callable actions, each with a JSON Schema describing its arguments. The model decides when to call one and what arguments to pass, the same way it would decide to call any function it has been given. Creating a ticket, running a query, writing a file are all tools.
- Resources are addressable data, each identified by a URI, that the host can read and hand to the model as context. The key difference from a tool is who initiates: a resource is something the host or user attaches, not something the model has to think to call. A file's contents or a database schema are typical resources.
- Prompts are reusable, parameterised prompt templates the server offers, letting a server ship its own recommended way of asking for something rather than leaving every host to reinvent the wording.
Most of what people mean when they say "MCP server" in casual conversation is tools; resources and prompts exist and matter, but tools are the primitive that gets exercised in nearly every session. A server can expose any mix of the three, and a client is free to support only the ones it needs.
why it matters once there is more than one agent
The integration-math argument from the first section compounds once you are running several agents rather than one. Say you run three coding agents in parallel, from two different tools, and all three need to read the same issue tracker. Without a shared protocol, that is a separate integration per tool, maintained separately, each with its own bugs and its own drift from the tracker's actual API. With MCP, it is one server, and every MCP-aware client connects to it unmodified.
That reframes tool access as infrastructure rather than as a property of any one agent. The server holding credentials for your database or your ticket tracker is a thing you stand up once, and it does not care whether the client on the other end is a terminal-based coding agent, an IDE's built-in assistant, or a browser extension. Swapping which agent tool you use day to day does not mean re-earning access to any of your systems.
It also changes what "adding a tool to your agent" costs. Historically, giving an agent a new capability meant writing glue code specific to that agent's plugin system. With MCP it means pointing the host at a server, which is why the growth of the MCP server ecosystem has been visible mostly as configuration, entries in a JSON file, rather than as code anyone had to write per integration.
what MCP does not solve
A shared protocol is not a shared trust model. A server you did not write can, within whatever permissions the host grants it, do anything its tools allow: read files, make network calls, run commands. MCP standardises how a tool is described and invoked, not whether it is safe to run. Treat an MCP server from an unfamiliar source the way you would treat any other third-party code with access to your machine, because that is what it is.
It also does not solve coordination between multiple agents sharing one server. A GitHub MCP server used by three concurrent agents will happily accept three concurrent tool calls; nothing in the protocol sequences them or stops two agents from opening conflicting pull requests. MCP standardises the connection between agent and tool, not the coordination between agents.