Model Context Protocol (MCP)

MCP, short for Model Context Protocol, is an open standard for connecting AI applications to the tools and data they need. An MCP server is a program that exposes one system, such as a Postgres database, a GitHub account or a folder of files, as a list of tools, data and prompt templates. Any application that speaks MCP can read that list and call what is on it: Claude, ChatGPT, VS Code, Cursor, or an AI agent you wrote yourself.

Anthropic released MCP on 25 November 2024. OpenAI added it to its Agents SDK in March 2025, and Google said in April 2025 that Gemini would support it. On 9 December 2025 the Linux Foundation formed the Agentic AI Foundation with MCP as a founding project, alongside Block's goose and OpenAI's AGENTS.md. The wire format is plain. Messages are JSON-RPC 2.0, a standard shape for requests and replies written as JSON.

We treat MCP as the way a call reaches a system and nothing more. Which tools the model sees, where the credentials live and which calls a person approves are still decisions in your own code, and the last section covers them.

What problem does MCP remove?#

Without a shared protocol, every AI application reaches every outside system through its own glue code. With M applications and N systems, wiring each pair costs M times N integrations, each with its own auth handling, error handling and upkeep. A company with four AI products (a chat assistant, an IDE agent, a support copilot, an internal workflow bot) and ten systems (Postgres, GitHub, Jira, Slack, the CRM and so on) faces forty integrations. With MCP it needs fourteen pieces: ten servers and four clients. The specification says it takes some inspiration from the Language Server Protocol, which did the same for code editors and programming languages.

The arithmetic only pays when several applications share the systems. One agent calling two of your own APIs needs two integrations with or without MCP, and a typed function in the agent's code is less to run than two servers. Bigcircle recommends building an MCP server when a second application will call the same system, or when an application you do not control, such as Claude or ChatGPT, has to reach it, because that is when the M times N cost appears.

How do hosts, clients and servers talk?#

There are three roles. The host is the AI application. The host creates one client for each server it connects to. The server is a program that exposes one system's capabilities in MCP's vocabulary: a Postgres server, a GitHub server, a filesystem server.

As of the 2026-07-28 specification, the protocol is stateless. The initialize handshake and protocol-level sessions are gone, along with the Mcp-Session-Id header. Every request carries its own protocol version and client capabilities. Every server must answer server/discover, which a client can call first to learn what the server supports. A server that needs state across calls mints its own handle and receives it back as an ordinary tool argument. Code written against the 2025-11-25 revision, which held a stateful connection, has to detect which revision the other side speaks and fall back.

Two transports carry the messages. Stdio is for local servers: the host launches the server as a subprocess and they exchange newline-delimited messages over standard input and output, which suits a filesystem or a database on the same machine. Streamable HTTP is for remote servers: each message is an HTTP POST to one endpoint, and the reply comes back as JSON or as a stream tied to that request. A protected HTTP server checks an access token on every request under OAuth 2.1, the authorization standard behind most "sign in with" flows, which our guide on how MCP authorization works covers.

Who decides when a capability is used?#

Servers offer three kinds of capability, and the difference is who decides when each one is used.

Primitive	Who decides	Example
Tools	The model, during its reasoning	create_ticket(title, priority), run_query(sql)
Resources	The application, which attaches them as context	A file, a table schema, a log stream
Prompts	The user, who picks one by name	A slash command that expands into a workflow

Tools are MCP's standard form of tool calling, and most of the design work on a server goes into them: how many, how large, and what they return, which our guide on designing MCP tools covers. A Postgres server might expose one query tool, each table schema as a resource so the model sees the shape of the data before it writes SQL, and an "explain this slow query" prompt the user runs by name. A workflow the agent should find and run on its own belongs in a tool, not a prompt, because only the user can pick a prompt.

Clients can also offer things back to servers. In the 2026-07-28 revision, elicitation, where the server asks the user a question, is the one client feature left in the core protocol. Sampling (the server asks the host's model to write something), Roots (the server asks which folders it may touch) and Logging are deprecated: they still work, new code should not adopt them, and the deprecation policy keeps them for at least twelve months. A server that needs input no longer sends its own request. It returns an input_required result listing what it needs, and the client retries the original request with the answers attached. Tasks, for long-running work, moved out of the core into an optional extension, the opt-in layer where MCP Apps, interactive UI shown inside a conversation, is also defined. Both sides have to support an extension before either can use it.

Why treat a third-party server as untrusted?#

A server's tool descriptions go straight into the model's context, and the user rarely reads them. Invariant Labs showed the risk on 1 April 2025 with what they called tool poisoning. A harmless-looking add tool carried hidden instructions in its description: read ~/.cursor/mcp.json and ~/.ssh/id_rsa, and pass their contents in an extra parameter. The agent did it, and the user saw only a simplified tool call. The same post described a rug pull, where a server changes its descriptions after you approved it, and shadowing, where one server's description redirected email meant for a trusted server's send_email tool to an attacker. Text a tool returns is model input too, so prompt injection can arrive through results.

The specification says hosts must get explicit user consent before invoking any tool, and that descriptions of tool behaviour should be treated as untrusted unless they come from a trusted server. A consent screen helps only when the user understands it. The risky case is an agent that can read private data, reads untrusted content, and can send data out, all in one run. Pin server versions, scope each credential to the least it needs, require a person to approve destructive or data-moving calls, and put guardrails and red-teaming on the agent as a whole rather than trusting each server.

Use the official registry at registry.modelcontextprotocol.io to find a server, not to vet one. A listing says where the package or the remote endpoint lives, and nobody has reviewed the code behind it on your behalf. The Linux Foundation counted more than 10,000 published servers in December 2025. A stdio server you wrote yourself and run on your own machine needs less of this. A hosted server someone else maintains needs all of it, because its descriptions can change without a release on your side.

What the specification leaves to you#

The protocol decides how a call reaches a server. It does not decide which tools the model should see or where the credentials live. On Solarpunk, the AI chief-of-staff desktop agent we built, credentials sit in an encrypted vault on the user's machine and are injected into the tool adapter when a tool runs, so they never travel into the prompt. The agent can act only through systems that were explicitly registered. Putting every tool in the system prompt worked until roughly thirty tools, after which the model started choosing plausible but wrong ones, so the model queries the tool registry instead of being handed all of it. That build has more than a hundred tools registered.

Both decisions sit in the code around the protocol, and an MCP deployment has to make them too. The 2026-07-28 revision helps with the first: a server may return a different tool list for different access tokens, such as only the tools the caller's scopes permit, though never a list that varies by connection. Use that to keep the catalogue a model sees as small as its grant, and keep the secrets in a vault the model cannot read.