Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

MCP (Model Context Protocol)

Pattern

A reusable solution you can apply to your work.

Context

At the agentic level, the Model Context Protocol (MCP) is an open protocol for connecting agents to external tools and data sources. It standardizes how an agent discovers available tools, how it invokes them, and how it receives results, regardless of who built the agent or who built the tool.

MCP sits at the intersection of the harness and the tool layer. Before MCP, each harness had its own mechanism for tool integration, meaning a tool built for one harness couldn’t be used with another. MCP provides a common language, similar to how HTTP standardized web communication or how LSP (Language Server Protocol) standardized code editor features.

In late 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF) under the Linux Foundation, with co-founding support from OpenAI, Block, Google, Microsoft, AWS, Cloudflare, and Bloomberg. The protocol is now governed as a vendor-neutral open standard.

Problem

How do you connect an agent to the growing world of external tools, data sources, and services without building custom integrations for each combination of agent and tool?

As agentic coding matures, the number of useful tools grows: code search, documentation lookup, database access, CI/CD control, issue trackers, deployment tools. Without a standard protocol, every tool must be integrated separately with every harness. This creates an O(n*m) problem: n tools times m harnesses, each requiring a custom integration.

Forces

  • Fragmentation: each harness defining its own tool interface prevents tool reuse.
  • Tool diversity: the range of useful tools is large and growing, making custom integration impractical.
  • Discovery: the agent needs to know what tools exist and what they can do, dynamically.
  • Security: connecting to external services introduces trust, authentication, and prompt injection concerns.
  • Simplicity: the protocol must be simple enough that tool authors actually adopt it.

Solution

MCP defines a standard interface between an agent (the client) and a tool provider (the server). An MCP server exposes one or more capabilities: tools the agent can call, resources the agent can read, or prompts the agent can use. The agent’s harness connects to MCP servers and presents their capabilities to the model as available tools.

The protocol works through a simple lifecycle:

  1. Discovery. The harness connects to an MCP server and asks what capabilities it provides. The server responds with a list of tools, each with a name, description, and input schema.
  2. Invocation. When the model decides to use a tool, the harness sends the call to the appropriate MCP server with the specified parameters.
  3. Response. The server executes the tool and returns the result to the harness, which includes it in the model’s context.

MCP supports two transport mechanisms. Stdio runs the server as a local subprocess, communicating over standard input and output. This is the simplest option for local tools like file access or database queries. Streamable HTTP treats the server as a standard HTTP endpoint, enabling remote MCP servers hosted anywhere on the network. The shift to Streamable HTTP transformed MCP from a local-tool protocol into a remote-service protocol, and the majority of large SaaS platforms now offer remote MCP servers for their APIs.

For remote servers, MCP uses OAuth 2.1 for authentication. The MCP server acts as an OAuth 2.1 resource server, accepting access tokens from clients. This means you can protect MCP endpoints with the same identity infrastructure your organization already uses, rather than inventing a proprietary handshake for each tool.

Tip

When choosing MCP servers for your workflow, start with a small set of high-quality servers that cover your most common needs (file access, code search, and your project’s primary external services). Adding too many servers at once increases the model’s decision space and can degrade tool selection quality.

How It Plays Out

A developer works with a coding agent that needs to query a PostgreSQL database during development. Rather than giving the agent raw SQL shell access, the team installs an MCP server that exposes read-only database queries with schema introspection. The agent can explore tables, run SELECT queries, and understand the data model, but it can’t modify or delete data. The MCP server enforces the boundary.

An open-source community builds an MCP server for a popular project management tool. Any developer using any MCP-compatible agent can now ask their agent to create issues, check project status, or update task assignments. The project management company didn’t build separate integrations for every coding assistant. One MCP server covers them all.

Example Prompt

“Connect to the PostgreSQL MCP server and explore the schema. Show me the tables related to orders, then write a read-only query that finds all orders placed in the last 24 hours with a total over $100.”

Consequences

MCP turns the tool ecosystem from a fragmented collection of custom integrations into an interoperable network. Tool authors build once and reach every MCP-compatible agent. Agent developers get access to a growing library of tools without building integrations. With over 97 million monthly SDK downloads, 10,000 active servers, and first-class client support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and VS Code, MCP has become the dominant standard for agent-tool communication.

The cost is the indirection of a protocol layer. MCP servers must be installed, configured, and maintained. For remote servers, authentication and authorization add operational complexity. And because MCP servers accept input shaped by model output, they are a primary prompt injection attack surface. Tool-poisoning attacks (where a compromised server injects malicious instructions into tool descriptions) and rug-pull attacks (where a server changes behavior after initial trust is established) are documented threats. OWASP published an MCP Top 10 security guide in early 2026. Treating MCP servers with the same skepticism you’d apply to any external dependency is the right default.

  • Refines: Tool – MCP standardizes how tools are exposed and invoked.
  • Uses: Harness (Agentic) – the harness manages MCP server connections.
  • Enables: Agent – MCP expands the capabilities available to agents.
  • Uses: Approval Policy – MCP tools should be subject to the same approval rules as built-in tools.
  • Related: Prompt Injection – MCP tool integrations introduce tool-poisoning and rug-pull attack surfaces.
  • Related: Tool Poisoning – MCP’s tool discovery mechanism is the primary vector for poisoning.

Sources

Anthropic introduced MCP in November 2024 as an open protocol for connecting AI agents to external tools and data, modeled on the Language Server Protocol’s success in standardizing editor-to-language-server communication.

The Agentic AI Foundation (AAIF), formed under the Linux Foundation in December 2025, now governs MCP as a vendor-neutral standard, with co-founding members including Anthropic, OpenAI, Block, Google, Microsoft, AWS, Cloudflare, and Bloomberg.

The Streamable HTTP transport and OAuth 2.1 authorization framework were formalized in the June 2025 specification update, enabling remote MCP servers and enterprise-grade authentication.