Model Context Protocol (MCP)

An AI agent's power is directly proportional to the quality and accessibility of the tools it can use. That principle, established in enterprise research on agentic AI systems, explains both the promise and the pain of agent integration. The ability to use external tools is what gives agents their power to affect the digital or physical world. Tools are registered with the agent along with natural language descriptions, allowing the LLM to select the appropriate tool via tool calling for a given sub-task.

But here's the problem. Before MCP, every agent-tool connection required a custom integration. If you had 10 agents and 15 tools, you needed up to 150 individual integrations. Each one with its own authentication logic, data format handling, error management, and maintenance burden. Add a new tool? You write a connector for every agent that needs it. Add a new agent? You write connectors for every tool it needs to access.

Agentic systems often need to interact with a multitude of existing enterprise systems, legacy applications, databases, and external APIs. Ensuring seamless, secure, and robust integration can be complex and resource-intensive, particularly with older systems not designed for API-driven interaction. This isn't a theoretical complaint. It's the number-one architectural bottleneck teams hit when moving from single-agent prototypes to production deployments.

MCP eliminates the quadratic scaling problem by introducing a universal protocol layer between agents and the systems they connect to. Build one MCP server for your tool, and every MCP-compatible agent can use it. Build one MCP client into your agent, and it can connect to every MCP server in the ecosystem. The same pattern that USB solved for hardware peripherals, MCP solves for agentic AI.

The Model Context Protocol (MCP) is an open-source standard for connecting AI applications to external systems. Created by Anthropic and released in late 2024, MCP provides a standardized way for AI agents to discover and interact with tools, data sources, and workflows at runtime, without requiring hardcoded, per-tool integrations.

The official documentation describes it best: "Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems." That analogy captures the core idea. Before USB, every peripheral needed its own proprietary connector. Before MCP, every agent-tool pairing needed its own custom glue code.

MCP is designed to make tools self-describing and discoverable, allowing agents to find and use them at runtime across different environments without brittle, hard-coded integrations. The protocol focuses solely on context exchange; it does not dictate how AI applications use LLMs or manage the provided context. That deliberate separation of concerns is what makes it composable across different frameworks, models, and deployment environments.

MCP uses JSON-RPC 2.0 as its wire protocol. Every message between client and server follows the JSON-RPC request-response or notification pattern, encoded as UTF-8. This is intentionally boring infrastructure. JSON-RPC is well-understood, widely supported, and easy to debug. The protocol's value isn't in novel wire formats; it's in the standardized semantics layered on top.

MCP follows a client-server architecture with three distinct participant roles. Understanding these roles is essential because MCP's security model depends on clear boundaries between them.

The architecture deliberately separates concerns. The host handles user-facing logic and security policy. Clients manage protocol-level communication. Servers encapsulate tool functionality. This three-layer model means you can swap any component without touching the others. A tool vendor builds one MCP server, and it works with Claude, VS Code, Cursor, and any other MCP host without modification.

MCP consists of two layers. The data layer defines the JSON-RPC message semantics: lifecycle management, capability negotiation, and the core primitives (tools, resources, prompts, notifications). The transport layer handles how messages physically move between client and server, including connection establishment, message framing, and authentication. This layering means the same protocol works identically whether you're connecting to a local filesystem process or a remote cloud API.

MCP defines three core primitives that servers expose. Understanding which primitive to use is one of the most important design decisions when building MCP servers. Each primitive answers to a different controller.

Each primitive type has standardized methods for discovery (*/list) and retrieval or execution (tools/call, resources/read). A client can first list all available tools, then invoke them as needed. Tool listings are dynamic: servers can notify clients when their capabilities change via notifications/tools/list_changed, and the client refreshes its registry automatically.

MCP also defines client-side primitives that flow in the opposite direction. Sampling allows servers to request LLM completions from the host, which is useful for server authors who want language model access without embedding an LLM SDK. Elicitation allows servers to request additional information from users, enabling confirmation dialogs or multi-step input flows. Both primitives keep the server lightweight while leveraging the host's capabilities.

Consider a database MCP server as a concrete example. It might expose tools for executing queries, a resource containing the database schema, and a prompt with few-shot examples for writing SQL in the correct dialect. The LLM uses the resource for context, follows the prompt's patterns, and invokes the tool to run the actual query. Three primitives, one cohesive interaction.

MCP's transport layer defines how client and server physically exchange messages. The protocol currently supports two standard transport mechanisms. The choice between them determines where your server runs, how it authenticates, and who can access it.

The Streamable HTTP transport replaced the older HTTP+SSE transport in the 2025 specification revision. It provides a single HTTP endpoint that handles both POST requests for client-to-server messages and optional SSE streams for server-initiated communication. This simplification reduced implementation complexity while adding features like session management (via Mcp-Session-Id headers) and resumable streams for reliability.

The transport layer abstracts communication details from the data layer, so the same JSON-RPC 2.0 messages work identically across both transports. A tool that works over stdio locally works over Streamable HTTP remotely with zero changes to the tool logic. Only the connection setup differs.

A critical security note for Streamable HTTP: servers must validate the Origin header on all incoming connections to prevent DNS rebinding attacks. When running locally, servers should bind only to localhost rather than all network interfaces. The MCP specification recommends OAuth for obtaining authentication tokens, and the protocol defines its own security best practices covering confused deputy prevention, SSRF mitigation, and session hijacking protections.

MCP's standardization of tool integration is a significant architectural improvement, but it concentrates risk. A security vulnerability within the protocol or a widely-used server implementation could be replicated across thousands of applications built upon it. The MCP specification addresses this with a detailed security best practices document that every implementor should read. We cover the broader security implications in depth in Tool Misuse, Excessive Agency, and the MCP Compositional Risk.

The broader agentic security context amplifies these concerns. Prompt injection can manipulate an agent into calling MCP tools with malicious parameters. Excessive agency means an agent granted too many tool permissions becomes a liability without proper guardrails if its reasoning goes sideways. A real-world exploit demonstrated how an agent could be instructed to silently exfiltrate Google Drive files through its legitimate tool connectors.

Important: while MCP specifies OAuth 2.0 for authentication, enforcement varies across implementations. Many community-built servers use less rigorous authentication. Organizations should verify the security posture of each MCP server before production deployment.

Enterprise best practices for MCP security align with the agentic threat landscape: treat every agent as a privileged Non-Human Identity (NHI) with unique cryptographic credentials. Apply strict Role-Based Access Control (RBAC). Enforce the Principle of Least Privilege. Before integrating any MCP server, conduct thorough security assessments of its data handling, permissions model, and supply chain provenance. Use an API gateway to centralize authentication, rate limiting, and monitoring across all MCP server connections. Track emerging MCP vulnerabilities on the Security News Hub.

MCP's trajectory from internal Anthropic experiment to industry-wide standard happened remarkably fast. In one year, it became one of the fastest-growing open-source projects in AI. The adoption timeline tells the story:

These figures reflect the ecosystem as of early 2026 and are growing rapidly. Verify current numbers at modelcontextprotocol.io.

The client ecosystem now spans AI assistants (Claude, ChatGPT, Gemini), development tools (Visual Studio Code, Cursor, Windsurf), and enterprise platforms (Microsoft Copilot, AWS Bedrock). Server implementations cover databases, cloud services (GitHub, Slack, Sentry, Notion), local filesystems, and custom enterprise APIs. Enterprise deployment support comes from AWS, Cloudflare, Google Cloud, and Microsoft Azure.

The vendor-neutral governance under the Linux Foundation matters for enterprise adoption. Organizations deploying MCP in production need assurance that the protocol won't be captured by a single vendor or subject to sudden breaking changes. The AAIF structure provides that stability while maintaining community-driven development.

MCP + A2A: The Complete Interoperability Stack

MCP solves agent-to-tool communication. A different problem, agent-to-agent communication, is addressed by Google's Agent-to-Agent (A2A) protocol, launched in April 2025 and now governed by the Linux Foundation alongside MCP. Where MCP standardizes how an agent discovers and invokes tools, A2A standardizes how agents from different vendors discover each other, delegate tasks, and report status.

A2A introduces Agent Cards, JSON documents that advertise an agent's capabilities, authentication requirements, and supported interaction modes, functioning as digital business cards for agents. The protocol defines a task lifecycle (submitted, working, input-required, completed, failed) that lets a client agent track delegated work without polling or guesswork. Version 0.3 added gRPC support, signed security cards, and extended Python SDK client-side capabilities.

The two protocols are complementary, not competing. In a production architecture, MCP handles the vertical integration (agent connects to databases, APIs, file systems) while A2A handles the horizontal integration (agent delegates subtasks to specialized agents built on different frameworks). An enterprise might use MCP to connect its customer service agent to CRM tools, then use A2A to let that agent delegate compliance checks to a separate governance agent built by a different team on a different stack. Over 150 organizations now support A2A, including Salesforce, SAP, MongoDB, and all major hyperscalers. For a deeper look at A2A in the context of cloud platforms, see the Cloud Agent Platforms comparison.

Building MCP servers is straightforward by design. The official SDKs in Python and TypeScript handle protocol negotiation, transport setup, and message routing. You define your tools, resources, and prompts; the SDK handles the MCP plumbing. The MCP Inspector provides a development tool for testing servers interactively before deployment.

For enterprise deployments, the architectural guidance from the broader agentic AI research applies directly. Design modular, single-purpose tools. Avoid creating monolithic MCP servers that perform multiple unrelated functions. Smaller, well-defined tools are easier to test, reuse, and secure. Centralize governance. Use an API gateway to publish and manage MCP servers. This allows for consistent enforcement of authentication, rate limiting, and security policies, keeping this logic separate from the tool's core function. For organizational AI governance strategy that spans tool governance and beyond, the AI Governance Hub covers responsible AI frameworks and accountability structures.

The scope minimization principle is critical. Start with minimal permissions (read-only access, basic discovery) and progressively elevate privileges only when specific operations require them. The MCP specification explicitly warns against using wildcard or omnibus scopes. An agent that can query your database is useful. An agent that can also modify schemas, drop tables, and access every database in the fleet is a liability waiting for a prompt injection to exploit it.

MCP's connection lifecycle follows a strict pattern: initialization (capability negotiation), operation (tool discovery and execution), and shutdown. The initialization handshake is where both client and server declare what they support. A server might advertise tools and resources but not prompts. A client might support sampling but not elicitation. This capability negotiation prevents runtime errors from mismatched expectations and provides clear documentation of what each component can do.

For organizations evaluating MCP alongside alternatives, here's the practical distinction. Native function calling (OpenAI, Claude, Gemini) works within a single model provider's ecosystem. It's simpler but locks you to one vendor's tool format. OpenAPI/Swagger describes REST APIs but doesn't address tool discovery, context injection, or LLM-specific interaction patterns. MCP sits between these, providing a universal protocol that works across model providers and handles the full agent-tool interaction lifecycle. If you're building tools that need to work with multiple AI platforms, MCP is the clear choice. If you're locked to a single provider and need maximum simplicity, native function calling may suffice.

The future direction is worth tracking. As covered in the A2A section above, Google's Agent-to-Agent protocol addresses communication between agents from different vendors, complementing MCP's agent-to-tool layer. Both protocols now sit under the Linux Foundation, and both are converging under the governance frameworks — including NIST AI RMF — and regulations like the EU AI Act that enterprises need for production deployment. The agentic AI market, projected to reach $107 to $199 billion by the early 2030s, will increasingly depend on these interoperability standards. Organizations adopting MCP now are building on the integration layer that the industry has collectively chosen. Follow protocol developments on the AI News Hub.