// PROTOCOL_EXPLAINER
MCP
Model Context Protocol
The universal standard for connecting AI models to external data sources and tools.
The Model Context Protocol (MCP) is an open protocol that standardizes how AI applications connect to external data sources, tools, and services. Introduced by Anthropic in November 2024, it defines a client-server architecture where an MCP host (like an IDE or AI assistant) communicates with MCP servers that expose resources, tools, and prompts. MCP eliminates the need for custom integrations between every AI model and every data source — one MCP server works with any MCP-compatible client.
// FIGURE_01 — MCP architecture overview: Anthropic · 2024 · stdio (local subprocess), Streamable HTTP (remote, with SSE streaming), JSON-RPC 2.0 message format
01What is the Model Context Protocol?
MCP is an open, JSON-RPC 2.0-based protocol that provides a standardized way for AI applications to access external context. Before MCP, connecting an AI assistant to a database, file system, or API required building a bespoke integration for each model-data pair. MCP decouples the integration layer: developers build an MCP server once, and any MCP-compatible client — Claude Desktop, Cursor, Zed, Windsurf — can consume it. The protocol specification is open-source and vendor-neutral, governed by Anthropic but contributed to by the community.
02How MCP Works: Client-Server Architecture
MCP follows a client-server model. The MCP Host is the application the user interacts with (an IDE, chat client, or agent framework). Inside the host, an MCP Client manages connections to one or more MCP Servers. Each server exposes capabilities — resources (read-only data like files or database rows), tools (executable functions the AI can call), and prompts (pre-defined templates). The host decides which resources and tools to expose to the underlying AI model based on context and user permissions. Communication happens over JSON-RPC 2.0, with servers running either locally (via stdio transport) or remotely (via HTTP+SSE or Streamable HTTP).
03The Five Primitive Types
MCP defines five primitives. Resources are read-only data sources the server exposes — files, database schemas, API responses. Tools are executable functions the AI can invoke, like running a query or sending an email. Prompts are reusable message templates that standardize interactions. Sampling allows servers to request LLM completions from the client, enabling reciprocal AI calls. Roots define the boundaries of the server's access — which directories, repositories, or endpoints it can touch. Together, these primitives cover the full surface area of model-context interaction.
04Transport Layers
MCP supports two transport mechanisms. The stdio transport runs the MCP server as a local subprocess, communicating over standard input/output — ideal for local tools like file system access or Git operations. The HTTP transport (Streamable HTTP, formerly HTTP+SSE) enables remote servers accessible over the network, supporting authentication, reconnection, and streaming. Both transports use JSON-RPC 2.0 as the message format, ensuring the same server logic works regardless of transport.
05MCP vs Function Calling
Function calling is a model-level feature where an LLM can request to call a function you've defined. MCP is a protocol-level standard that defines how hosts discover, expose, and execute those functions. Function calling is the mechanism; MCP is the infrastructure. An MCP server's tools are ultimately invoked via the host's function calling capability, but MCP adds discovery, schema validation, permission boundaries, and a universal interface that works across all compatible clients.
06MCP vs A2A: Complementary, Not Competing
MCP and A2A solve different problems. MCP connects an AI agent to tools and data sources — it's agent-to-infrastructure. A2A connects AI agents to each other — it's agent-to-agent. A single agent might use MCP to access a database and A2A to delegate a subtask to another agent. They operate at different layers of the stack and are designed to coexist. MCP handles the context layer; A2A handles the collaboration layer.
// KEY_CONCEPTS
Core Concepts
Resources
Read-only data sources exposed by the server — files, database rows, API responses. Identified by URIs.
Tools
Executable functions the AI model can call. Defined by a JSON Schema for parameters and a handler function.
Prompts
Reusable message templates that standardize interactions. Can accept arguments and be listed by the client.
Sampling
Server-initiated LLM completions. Allows an MCP server to ask the client's model to generate text, enabling recursive agent patterns.
Roots
Boundary definitions that limit what a server can access — filesystem directories, repository paths, or API scopes.
JSON-RPC 2.0
The message format used for all MCP communication. Lightweight, stateless, supports notifications and requests.
// ARCHITECTURE
How It Works
MCP Host
The user-facing application (IDE, chat client, agent framework) that orchestrates AI interactions.
MCP Client
Embedded in the host, manages connections to multiple MCP servers and routes messages.
MCP Server
Exposes resources, tools, and prompts. Can be local (stdio) or remote (HTTP). Built once, used by all clients.
Transport Layer
Carries JSON-RPC 2.0 messages — stdio for local, Streamable HTTP for remote.
// TRANSPORT_LAYERS
- stdio (local subprocess)
- Streamable HTTP (remote, with SSE streaming)
- JSON-RPC 2.0 message format
// USE_CASES
When to Use MCP
IDE integration — connect code editors to linters, type checkers, and documentation
Database access — let AI agents query SQL databases through a standardized interface
File system operations — read, write, and search local files with permission boundaries
API integration — wrap any REST or GraphQL API as an MCP server
Enterprise tooling — connect Jira, Slack, GitHub, internal tools through one protocol
// SUPPORTED_AGENTS
Agents Using MCP
// PROTOCOL_COMPARISON
MCP vs Other Protocols
| Aspect | MCPCURRENT | A2A | ACP |
|---|---|---|---|
| Primary purpose | Agent-to-tool/data connection | Agent-to-agent communication | Agent-to-agent via REST |
| Architecture | Client-server (host-client-server) | Client agent → remote agent | REST endpoints |
| Message format | JSON-RPC 2.0 | JSON-RPC 2.0 over HTTP | HTTP REST / OpenAPI |
| Transport | stdio, Streamable HTTP | HTTP + SSE | HTTP REST |
| Governance | Anthropic (open spec) | Google (open spec) | Cisco / BeeAI (open spec) |
| Released | November 2024 | April 2025 | 2025 |
// FAQ
Frequently Asked Questions
// WRITTEN_BY
Laurent Yew
Founder
Laurent Yew is the founder of AgentResourceDB, where he leads the platform's vision of building a unified, trust-first discovery layer for the AI agent ecosystem. With over a decade of experience scaling AI and SaaS products, Laurent has dedicated his career to making complex developer infrastructure accessible, transparent, and reliable. He writes about agent registries, protocol interoperability, and the future of agent-to-agent collaboration, drawing from hands-on work building evaluation frameworks that help developers cut through the noise of 100,000+ agents. Through AgentResourceDB, he is committed to establishing the trust standards the industry needs as AI agents move from experimentation to production.
// EXPLORE_MORE
Discover Agents by Category
Browse MCP-compatible agents across 15 categories — from coding and research to security and DevOps.
BROWSE_CATEGORIES