What Is the Model Context Protocol (MCP)?
Model Context Protocol (MCP) is an open standard for connecting AI models and agents to external tools, data sources, and services through a unified interface. Originally developed by Anthropic, MCP provides a standardized way for AI systems to discover, authenticate with, and invoke tools without custom integration code for each service. In March 2026, MCP adoption accelerated with Google's WebMCP enabling declarative tool registration directly in website HTML, the Agent Browser Protocol embedding MCP servers into Chromium, and Gemini CLI shipping with native MCP support. The protocol is becoming the de facto standard for tool interoperability across AI providers.
Why it matters
Before MCP, every AI tool integration was bespoke. If you wanted Claude to access your CRM, you built a custom integration. If you wanted GPT to query your database, you built another one. Each AI provider had its own function calling format, authentication requirements, and tool registration mechanism. This fragmentation meant that tool authors had to build N integrations for N AI providers, and enterprises had to maintain a growing web of custom connectors. MCP eliminates this N×N problem by providing a single protocol that any AI model can use to discover and invoke any tool. One MCP server implementation works with Claude, GPT, Gemini, and any other MCP-compatible model. This is the same pattern that made USB universal — a shared interface standard that benefits all participants.
How it works
MCP defines three core primitives. Tools are executable functions that an AI model can invoke — each tool has a name, description, input schema, and output type, allowing models to understand what the tool does and how to call it. Resources are read-only data sources that provide context to the model, such as files, database records, or API endpoints. Prompts are templated instructions that guide the model's interaction with tools and resources. An MCP server exposes these primitives over a transport layer (typically stdio for local servers or HTTP with Server-Sent Events for remote ones). The AI client discovers available tools, resources, and prompts through a capability negotiation handshake, then invokes them using structured JSON-RPC messages. Authentication, error handling, and capability versioning are all part of the protocol specification.
Limitations: The Per-Source Scaling Problem
While MCP solves tool discoverability, real-world benchmarks reveal a structural limitation when agents need to combine data across multiple sources. Each MCP server wraps a single API, so cross-source questions ("which churned customers have open support tickets?") require the agent to make sequential tool calls, paginate through JSON payloads, and attempt to correlate results in its context window. Dinobase benchmarks across 11 LLMs showed that this per-source MCP pattern achieves only 35% accuracy on cross-source queries, compared to 91% when data is pre-unified into a single SQL layer. This has spurred interest in agent-first data architectures that complement MCP by providing a unified query interface for enterprise data, while MCP continues to excel for discrete, single-service tool operations.
Example
A company builds an MCP server for their project management system. The server exposes tools like 'create_task,' 'list_sprints,' and 'assign_user,' plus resources like the current sprint board and team member list. Once deployed, any MCP-compatible AI assistant can discover these tools and use them in conversations. A developer using Claude can say 'create a task for the login bug and assign it to Sarah' and Claude discovers the create_task and assign_user tools via MCP, invokes them with the correct parameters, and confirms the result. The same MCP server works unchanged when the company's product team uses Gemini, or when their CI pipeline uses an automated agent — no new integration code needed.