FAQS
No items found.
The Model Context Protocol (MCP) is an open standard that connects AI applications, including agents, to external tools and data through a single, uniform interface. Think of MCP like a USB-C port for AI applications. USB-C standardizes how electronic devices connect to each other, and MCP standardizes how AI applications connect to external systems.
Anthropic introduced MCP in November 2024. MCP is not an agent framework, it is a standardized integration layer for AI agents accessing tools, and the model, not the protocol, decides when a tool is called. In December 2025, Anthropic donated MCP to the Agentic AI Foundation. The Agentic AI Foundation is a directed fund under the Linux Foundation, co-founded by Anthropic, Block, and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg.
MCP works through a client-host-server architecture. A host creates one client per MCP server, each client keeps an isolated connection, and servers expose the capabilities the model calls. Client and server exchange JSON-RPC 2.0 messages over one of two transports. Earlier revisions through 2025-11-25 used an initialization handshake and could maintain protocol-level sessions; the current 2026-07-28 revision is stateless at the protocol layer. Servers expose tools, resources, and prompts through an optional authorization layer.
The host is the container and coordinator. It creates and manages multiple client instances, controls connection permissions and lifecycle, enforces security policies and consent, and coordinates the AI model across clients. Each client is created by the host and maintains an isolated connection to one server, routing messages and keeping security boundaries between servers. Servers are lightweight processes that expose resources, tools, and prompts, handle requests, and respond with data or outcomes. By design, a server should not read the whole conversation or see into other servers.
The JSON-RPC 2.0 wire format is the data layer. JSON-RPC is a lightweight message format for remote calls, and the MCP spec encodes every message in it. Those messages must be UTF-8 encoded. MCP takes inspiration from the Language Server Protocol, which standardizes how development tools add support for programming languages.
The protocol defines two standard transports, stdio and Streamable HTTP. In the stdio transport, the client launches the server as a subprocess, and the two exchange JSON-RPC messages over standard input and standard output. In the Streamable HTTP transport, the server runs independently, and the client sends every message as its own HTTP POST request. Earlier revisions also used HTTP GET for streaming; the current revision restricts Streamable HTTP to POST. Streamable HTTP replaced the older HTTP+SSE transport, which paired HTTP with Server-Sent Events (SSE) for streaming, so current deployments use these two options.
Earlier MCP revisions through 2025-11-25 used an initialization handshake and could maintain protocol-level sessions. The 2026-07-28 revision removed that handshake and the mandated lifecycle, so current MCP requests can stand alone.
Servers expose three primitives: tools, resources, and prompts. Tools are functions the model can actively call. They are model-controlled, and they may require user consent before execution. Resources are passive data sources that provide read-only context for the model, and the application controls them. Prompts are pre-built instruction templates that tell the model how to work with specific tools and resources, and the user controls them.
Authorization is optional in MCP. Over HTTP transports, a protected server acts as an OAuth 2.1 resource server, and the MCP client acts as an OAuth 2.1 client. This lets a client call a restricted server on behalf of the person or system that owns the protected data, called the resource owner. Over stdio, implementations should retrieve credentials from the environment instead. Because authorization is optional, servers and clients define the enforcement policy, not the protocol.
The 2026-07-28 revision made MCP stateless at the protocol layer. It removed the initialization handshake and protocol-level session tracking. Protocol version, client identity, and capabilities now travel with each request. The earlier 2025-11-25 specification supported the stateful session model; the current revision lets each request stand alone.
The same revision deprecated roots, sampling, and logging. It also introduced Multi Round-Trip Requests (MRTR) for interactions that previously relied on server-to-client requests, while Tasks for long-running operations moved into the optional extensions framework. These changes are not all backward compatible.
MCP matters for agent governance because it replaces connector sprawl with one standard. Before MCP, developers built custom connectors for each data source or tool. Anthropic described that as an N×M problem, meaning every tool needed its own integration with every application. AI products including ChatGPT, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code support it, and enterprise-class infrastructure for MCP exists across AWS, Cloudflare, Google Cloud, and Microsoft Azure.
The isolation-by-design architecture is itself a governance advantage. By design, servers should not be able to read the whole conversation or see into other servers, which limits how far a single compromised integration can reach. The standard's governance now also sits in a neutral home, the Agentic AI Foundation under the Linux Foundation. The protocol provides little governance on its own, so enterprises place an MCP gateway in front of servers. Gateway controls include:
MCP, APIs, RAG (Retrieval-Augmented Generation), function calling, and A2A (Agent2Agent) solve different problems and work together. An API is a capability contract one system exposes to another. RAG supplies pre-retrieved context for the model to read, while MCP gives the model live access to tools and data the model can act on. Function calling is the model-side mechanism that invokes a function, and MCP standardizes how tools are exposed and called. A2A connects independent agents to each other.
In summary, MCP standardizes the connection, APIs define capabilities, RAG supplies context, function calling invokes tools, and A2A connects agents. The sharpest distinction is between MCP and A2A. MCP is a single hierarchical exchange, with an agent calling down to a passive server. A2A is peer-to-peer, linking independent autonomous agents. The two protocols are complementary, and teams reach for A2A when work delegates across a boundary they do not control.
Documented MCP security risks cluster at the boundary between models and the tools they call. In April 2025, security researchers released an analysis finding outstanding issues such as prompt injection and poisoned tools that allow data exfiltration through connected tools. A 2025 academic survey mapped the full MCP server lifecycle, from creation through maintenance, to a distinct set of threat scenarios. Specific risks documented in the specification:
Authorization is optional in MCP, so the enforcement posture is the security posture. Defenders should implement a progressive, least-privilege scope model. Gateways back that posture by blocking on unexpected errors, routing sensitive tools for approval, and redacting audit payloads, so a defensive failure blocks the call instead of letting it through.
The Model Context Protocol is the integration standard for connecting AI applications to the systems they call, and it replaced per-tool connectors with one open interface. Its current revision is stateless at the protocol layer, and its governance now sits in a neutral foundation. The durable takeaway is the protocol standardizes the connection, and enterprise governance decides what that connection may do.
Frequently asked questions cover the most common points of confusion about MCP.
The Model Context Protocol (MCP) is an open standard that connects AI applications to external tools and data through a single, uniform interface. Anthropic introduced MCP in November 2024, and a neutral foundation now governs it.
MCP works through a client-host-server architecture. The host creates one client per server; messages travel as JSON-RPC 2.0 over stdio or Streamable HTTP; servers expose tools, resources, and prompts; and the current 2026-07-28 revision is stateless at the protocol layer. Earlier revisions through 2025-11-25 used an initialization handshake and could maintain protocol-level sessions.
MCP is used to give AI applications a single standard way to reach external tools and data. Teams use it to let agents read documentation, query live services, run tools, and work through governed access points such as an MCP gateway.
An MCP server is the program that exposes tools, resources, and prompts through the protocol. It runs as a separate process, and the host connects to it through one dedicated client per server.
No. MCP is not an agent framework; it is a standardized integration layer for agents accessing tools. The model, not the protocol, decides when a tool is called.
Yes. MCP has been stateless at the protocol layer since the 2026-07-28 revision. The revision removed protocol-level session tracking, and protocol version, client identity, and capabilities now travel in a _meta parameter with each request. Earlier revisions were stateful.
No. APIs remain the capability contracts behind the tools; function calling remains the model-side invocation mechanism; and MCP standardizes how the two are exposed to the model. The layers work together rather than replace one another.
MCP connects an agent to its tools and data. A2A connects independent agents to each other. MCP is a single hierarchical exchange, while A2A is peer-to-peer, and the two protocols are complementary.
MCP's documented security risks include prompt injection, poisoned tools, and data exfiltration through connected tools. Spec-level risks include confused deputy attacks and server-side request forgery. The enforcement posture around authorization, including fail-closed gateways, is what makes MCP secure in practice.
Most teams can spin up an agent. Few can deploy one their security team signs off on. Here's the framework that does both.
Give them a Basecamp. Go from AI chaos to AI work, in minutes.
