MCP Foundations and Architecture
What MCP is
The Model Context Protocol (MCP) is an open standard for how AI systems — particularly agentic large language models — connect to real-world data and tools. Instead of every assistant, IDE, or chatbot hand-building integrations for each service it touches, MCP defines one interface that any model can speak and any tool can implement. It is often described as the USB-C of AI: a single, predictable plug between reasoning engines and the systems they act on.
The protocol was introduced by Anthropic in 2024 and adopted quickly across the industry — by OpenAI, Microsoft, Google, JetBrains, Supabase, and others — making it a foundational layer of the agentic AI stack.
The value is combinatorial. Without a standard, connecting M applications to N tools is an M × N integration problem. MCP collapses it to M + N: build a server once, and every compliant client can use it.
The three roles
MCP is a client-server protocol, but its terminology is tailored to AI. Three roles do the work.
| Role | Responsibility | Examples |
|---|---|---|
| Host | The user-facing application where the model runs. Manages sessions, user input, permissions, and result display. | Claude Desktop, ChatGPT, Cursor, VS Code |
| Client | A component inside the Host that speaks MCP to one server. Handles discovery, the message loop, and request IDs. | The MCP client embedded in Claude, Cursor, or Copilot |
| Server | A wrapper around a real resource — a database, API, or filesystem — that exposes a structured, discoverable interface. | Supabase MCP, Chrome DevTools MCP, a WordPress MCP |
A useful division of labor: the Host decides what to do, the Client knows how to say it in MCP terms, and the Server knows how to execute it against the underlying system. A Host may run several Clients at once, one per connected Server. Servers can run locally on the same machine or remotely in the cloud; the interface is identical either way.
Protocol layers
MCP separates concerns into three layers.
Transport
How bytes move between Client and Server:
- stdio (local) — the Server runs as a subprocess and exchanges JSON-RPC frames over standard input/output. Best for CLI tools, IDEs, and local development: low latency, no network surface.
- Streamable HTTP (remote) — a persistent HTTP endpoint suitable for cloud and multi-tenant deployments, including streaming of large or incremental responses.
The 2025 spec revision replaced the earlier Server-Sent Events (SSE) transport with Streamable HTTP; treat SSE as legacy.
Message format
Every exchange uses JSON-RPC 2.0 — a minimal, human-readable RPC schema. Requests and responses are explicitly typed and carry an id for correlation:
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": { "name": "execute_sql_query", "arguments": {} },
"id": "1234"
}
Because the wire format is plain JSON, exchanges are easy to log, replay, and audit.
Capabilities (primitives)
The capability layer is where a Server declares what it can do. MCP defines three primitive types:
| Primitive | What it is | Example |
|---|---|---|
| Tools | Executable functions the agent can call (actions, often state-changing). | execute_sql_query, create_post, navigate_page |
| Resources | Read-only data the agent can pull into context. | file:///reports/q3.pdf, db://sales/stats |
| Prompts | Parameterized templates that guide a task. | “Summarize document”, “Compare product metrics” |
Together these form a language-agnostic API surface that any model can discover at runtime rather than being hard-coded against.
How a request flows
A single interaction moves through a predictable loop:
User → Host → Client → Server → External System → Client → Host → User
- Discovery — the Client locates available Servers via configuration or a registry.
- Negotiation — the Client calls
tools/list(andresources/list) to learn what each Server exposes. - Selection — the model maps its intent to a specific tool and arguments.
- Transport — the request travels as JSON-RPC over stdio or HTTP.
- Execution — the Server translates the call into underlying system actions and returns a normalized result.
- Aggregation — the Client merges results across Servers if needed.
- Presentation — the Host renders the answer to the user.
This loop lets a model operate on live systems without bespoke, per-tool API code.
Design principles
A few ideas from mainstream software architecture give MCP its shape:
- Composability — build a Server once, reuse it across every client.
- Security by boundary — each Server enforces its own scopes and capabilities, containing what a model can do.
- Transparency — JSON schemas and logs are human-readable, so exchanges can be audited and debugged.
- Extensibility — new primitives or transports can be added without breaking existing implementations.
Where MCP sits in the stack
MCP occupies the integration layer of the emerging agent stack, abstracting tool access the way REST once standardized API access:
Applications (chat apps, AI-enabled IDEs)
│
Orchestration (agent frameworks and SDKs)
│
Integration (MCP) (MCP clients + MCP servers)
│
Data & System APIs (databases, SaaS APIs, local tools)
Frameworks above the line plug into enterprise data, cloud APIs, and local utilities through a single protocol rather than a tangle of adapters.
MCP vs. legacy integration
| Dimension | MCP | Traditional API / plugin |
|---|---|---|
| Discovery | Standardized (tools/list) |
Manual, read the docs |
| Communication | JSON-RPC over a common transport | Custom HTTP or SDK calls |
| Security | Scoped per tool | Often app-level, coarse |
| Portability | Any compliant client | App-specific |
| Extensibility | Add transports/primitives | Often a rebuild |
| Auditability | Transparent JSON logs | Frequently opaque |
Open questions
The standard is maturing, and a few tensions are worth tracking:
- Concentration — capability is clustering around a handful of high-traffic servers.
- Trust — open, unaudited third-party servers introduce supply-chain and verification risk.
- Consistency — transports and features are still unevenly implemented, producing variable latency and behavior.
- Governance — versioned discovery, sandboxing requirements, and dynamic consent interfaces are active areas of work, especially for enterprise deployment.
Related reading
- MCP Connectors and Integrations — how servers bridge to real systems.
- MCP Reference and Use Cases — worked examples across domains.
- MCP Security and Compliance — securing the stack.
- AI Agents Running Workflows
- Advanced Multimodal RAG — when a standard RAG pipeline is insufficient for images and tables.
MCP turns a language model from an isolated reasoning system into a connected, action-capable worker. By fixing the roles (Host, Client, Server) and standardizing the wire format (JSON-RPC), it scales from a single local automation to enterprise-grade integration — the way HTTP standardized the web, applied to tool access for AI.
