MCP is an open standard for connecting AI agents to external tools, released by Anthropic in November 2024, adopted by OpenAI, Google DeepMind, and AWS, and donated to the Agentic AI Foundation in December 2025; cumulative SDK downloads exceed 97 million.

The design borrows from the Language Server Protocol, which standardized how code editors understand programming languages. Without a shared protocol, every AI application needs a custom integration for every tool it touches: N×M integrations. With one, each application implements a client once and each tool implements a server once: N+M. That reduction is the entire point. MCP is plumbing, not intelligence. It does not decide what an agent does, only how it reaches the tools it needs. Docker's MCP Catalog already hosts more than 270 servers with container isolation. The protocol fits the pattern of AI as normal technology: infrastructure that disappears into the background once it works.

An MCP setup has three parts. The host is the AI application that starts connections, such as Claude Code or Cursor. A client is a connector inside the host that maintains a one-to-one session with a server. The server is the service providing capabilities. Messages use JSON-RPC 2.0 over stdio for local processes or Streamable HTTP for remote servers.

A server offers three capability types. Tools are actions the AI can request, each described by a name, description, and JSON Schema for inputs. Resources are structured data the AI can read, identified by URIs, without a tool call. Prompts are predefined templates that structure interactions. Tools can carry safety annotations such as readOnlyHint and destructiveHint, which declare non-binding safety properties like read-only or destructive intent.

Compared with vendor-specific function calling, MCP moves tool definition and execution from the client to the server. Discovery happens at runtime through a tools/list request instead of a static upfront list. Sessions are stateful, with lifecycle management, rather than stateless calls. The November 2025 specification added asynchronous tasks, parallel tool calls, and OAuth 2.1 authorization. The practical difference: an app built on MCP can attach a new tool without rewriting its integration layer.

Tool definitions cost the model context before any work happens. A single GitHub server can consume about 20,000 tokens. Each server advertises its complete tool list when it connects. The protocol has no mechanism for a client to request only the tools a task needs. Connecting five well-built servers can spend a six-figure token budget on definitions for tools that are never called. The cost is invisible until the model starts reasoning: the context window is already partially consumed before the first real question is asked.

Gateways such as Rube respond with meta-tools: a search tool and a planner tool stay loaded and fetch real definitions on demand. This lazy-loading approach keeps the context window lean until a specific capability is actually needed. The general lesson is that capability breadth and reasoning quality trade off through the context window. The same constraint shapes the Loop Engineering approach to agent design: the reasoning loop degrades when the context window is crowded with definitions that never get used.

Security stays the deployer's job. Recommended practice for live databases is a dedicated read-only database user and MCP servers run in read-only mode. Enterprise deployments put a unified proxy in front of MCP servers for a central audit trail, runtime detection and redaction of personal data, and consistent authentication, responsibilities the protocol itself does not handle. The protocol's safety annotations are declarations, not enforcement.

MCP answers how one agent uses many tools. Agent-to-agent coordination is a separate emerging standard: A2A. In A2A, agents publish capability descriptions called agent cards and delegate tasks to one another. Production systems increasingly use both: MCP for tool access inside an agent, A2A for routing work between specialized agents. The two protocols solve different problems, and neither replaces the other.