Model Context Protocol (MCP)

What MCP is

Model Context Protocol is an open protocol for connecting AI applications to external context and tools through a standardized client-server interface. Instead of every application implementing custom, one-off integrations with every data source and tool, an MCP server exposes a consistent set of capabilities — resources, tools, and prompts — that any MCP-compatible client can consume. The protocol specifies the transport (stdio for local processes, Streamable HTTP for remote services) and the message format, not the specific tools a given server provides.

Why it matters for agent builders

Before MCP, connecting an agent to a database, a file system, or a SaaS API meant writing and maintaining a custom integration for each combination of framework and tool. MCP decouples the two: a tool author builds one server, and it works with any client that speaks the protocol — Claude Desktop, an IDE extension, or a custom agent runtime. This is a genuine reduction in integration surface area, but it does not by itself guarantee a given server is secure, actively maintained, or feature-complete; those remain separately verifiable facts about each specific server.

The three primitives

MCP defines three things a server can expose to a client, and the distinction matters for evaluating what a given server actually does:

A server that only exposes tools and a server that exposes resources, tools, and prompts are both valid MCP servers — the primitive count isn't itself a quality signal, but it does tell you what interaction patterns the server actually supports before you integrate it.

Transports: stdio vs. Streamable HTTP

stdio runs the MCP server as a local subprocess and communicates over standard input/output. It has no network exposure by default — the server only runs when the client starts it, and only the client that spawned it can talk to it. This is the default choice for local development and for tools that need filesystem or local-process access.

Streamable HTTP exposes the server over a network endpoint, which is what remote and multi-client deployments need — a team sharing one server instance, or a server that needs to run independently of any single client's lifecycle. It brings the usual web-service concerns with it: authentication, TLS, and rate limiting are the operator's responsibility, not something the protocol enforces for you.

What MCP does not guarantee

The protocol standardizes the interface, not the implementation. Adopting MCP tells you nothing on its own about whether a specific server validates its inputs, sandboxes command execution, rate-limits requests, or handles authentication correctly — those are properties of each individual server's code, and need to be checked per server rather than assumed from protocol compliance. A tool-calling interface that lets a model execute arbitrary shell commands is exactly as dangerous over MCP as it would be over any other transport if the server doesn't constrain what commands are allowed.

Knowledge clusters

A dedicated MCP server registry

This hub covers MCP in the context of the broader agent evidence graph — how it relates to frameworks, agents, and the entities that implement it. For a registry focused specifically on discovering and comparing MCP servers across a wider catalog, see MCPServer.in, a companion directory dedicated to MCP server listings.

Related pages

• Builder silo (frameworks, MCP, agents)
• Evidence methodology
• Agent frameworks directory