Model Context Protocol (MCP)

Learning Objectives

• Explain what MCP is and why it matters for the AI agent ecosystem
• Describe how MCP servers and clients work together
• Identify practical MCP servers relevant to coding, productivity, and enterprise workflows

The Integration Problem Before MCP

Before MCP, every AI product had to build its own integrations with every external tool. If you wanted Claude to read your Notion documents, Anthropic had to build a Notion integration. If you wanted it to query your Postgres database, a custom integration was needed. If you wanted it to check your GitHub issues — another one.

This created an O(n²) problem: for n AI products and n tools, you needed up to n² integration points. Each integration was built differently, maintained separately, and broke independently. The result was a fragmented ecosystem where no AI tool had access to everything users needed.

Model Context Protocol (MCP) solves this by standardizing the interface. Build one MCP server per tool — once — and any MCP-compatible agent can use it. The problem collapses from O(n²) to O(n).

What MCP Is

Model Context Protocol is an open standard that defines how AI agents communicate with external tools, data sources, and services. Specifically, it defines:

• How an agent discovers what tools are available (a server capability manifest)
• How an agent requests that a tool be used (a standard RPC-style call format)
• How results are returned (a standard response format the agent can understand)
• How resources and context are exposed (files, database records, knowledge bases)

MCP has three core primitives, plus two newer capabilities:

Tools — Functions the agent can invoke. A Slack MCP server exposes tools like send_message, list_channels, get_thread. A database MCP server exposes execute_query, list_tables. The agent reads the tool descriptions and decides when to call them.

Resources — Data sources the agent can read. File contents, database records, API data. The agent can browse and access these without writing code.

Prompts — Reusable templates that help the agent use the server correctly. Pre-built instructions for common workflows.

Sampling — Allows MCP servers to request LLM completions from the client, enabling more sophisticated server-side logic where the server can ask the agent's model to reason about data before returning results. Sampling was deprecated in the July 2026 spec (see below) and will keep working for at least twelve months, but new servers should not build on it.

Elicitation — Allows servers to request structured human input during execution. The server defines a schema describing what it needs, and the client presents the request to the user. This supports workflows where human judgment is needed mid-task. As of the July 2026 spec, elicitation is handled through Multi Round-Trip Requests rather than a server-opened stream.

History and Adoption

MCP was originally developed by Anthropic as an internal standard for Claude's tool integrations. In 2025, Anthropic donated MCP to the Agentic AI Foundation (a Linux Foundation project), making it vendor-neutral and community-governed. The protocol is now shaped through formal Working Groups, Spec Enhancement Proposals (SEPs), and a governance process open to the community.

The spec has evolved significantly since v1.0. An earlier release introduced Streamable HTTP transport, replacing the original server-sent-events transport and enabling remote MCP servers that handle multiple client connections over standard HTTP. That shift moved MCP from local-only tool connections toward remote deployment.

The July 2026 rewrite: MCP goes stateless

The July 28, 2026 specification finished that job by removing state from the protocol core. The initialize handshake and the protocol-level session identifier are gone, and every request is now self-contained.

That sounds like plumbing, and it is — but it was the single biggest barrier to running MCP at enterprise scale. A stateful protocol means every request from a given client has to reach the same server instance, which forces either sticky sessions or shared session storage. A stateless one does not: a remote MCP server can now sit behind an ordinary round-robin load balancer, scale horizontally, and survive an instance dying mid-conversation.

Three companion changes come with it:

• Multi Round-Trip Requests replace server-initiated messages. When a server needs input mid-call, it returns a result asking for it rather than holding a stream open.
• Routing headers let gateways and rate limiters dispatch a request without parsing its body.
• Cacheable list results carry a time-to-live, so clients stop re-fetching an unchanged tool catalog on every connection.

Authorization also moved closer to standard OAuth and OpenID Connect practice, replacing dynamic client registration with Client ID Metadata Documents.

The adoption has been exceptional:

• OpenAI adopted MCP in its agents framework and the Agents SDK
• Google integrated MCP into Gemini's tool use system and Gemini CLI
• Microsoft added MCP support to GitHub Copilot and VS Code
• Cursor, Windsurf, Zed, JetBrains, Xcode all support MCP in their IDEs
• 97 million+ monthly SDK downloads across the Python and TypeScript SDKs
• 34,700+ dependent projects on the TypeScript SDK alone
• 5,000+ community-built MCP servers covering everything from Slack to Notion to Kubernetes

MCP now runs in production at companies large and small, powering agent workflows across Fortune 500 enterprises. This cross-industry adoption transforms MCP from an Anthropic product into industry infrastructure — similar to how HTTP standardized the web.

How MCP Works in Practice

The architecture is a client-server model:

MCP Server: A process (local or remote) that exposes tools and resources. A developer (or a company) writes the server once and publishes it. Anyone can use it.

MCP Client: The AI agent or IDE. It connects to one or more MCP servers, discovers their capabilities, and calls their tools during a session.

Example walkthrough for a developer using Claude Code with a Supabase MCP server:

1. Developer configures the Supabase MCP server (providing database connection credentials)
2. Claude Code connects to the server and receives a list of available tools: execute_sql, list_tables, get_schema, create_table
3. During a coding session, Claude Code needs to check the database schema. It calls get_schema via MCP
4. The MCP server queries Supabase and returns the schema as structured JSON
5. Claude reads the schema and writes accurate code that references the real table and column names

Without MCP: Claude would have to guess at the schema, potentially writing code with wrong column names that fails at runtime. With MCP: it reads the real schema and writes correct code.

Practical MCP Servers

For developers:

For productivity:

For enterprise:

AGENTS.md — Project-Specific Agent Instructions

MCP handles tool connectivity. AGENTS.md handles project knowledge.

An AGENTS.md file in your project root is a structured document that tells AI coding agents everything they need to know about working effectively in your specific codebase:

• What the project does and who it's for
• The tech stack and versions in use
• How to run the development server and tests
• Coding conventions (TypeScript, naming, file organization)
• Files and directories to never modify
• How deployment works
• Common gotchas and known issues

The concept is supported across all major coding agents, though each tool uses its own filename: CLAUDE.md for Claude Code, AGENTS.md for OpenAI Codex, copilot-instructions.md for GitHub Copilot, and .cursor/rules for Cursor. The pattern is the same — a structured file that persists project knowledge so every new agent session starts informed rather than from zero.

The Bigger Picture

MCP represents a significant architectural shift in how AI is deployed. Instead of building vertical silos (one AI product that does everything for one category of work), MCP enables composable AI systems: any agent, any tool, any data source — mix and match.

The practical implication: as MCP adoption grows, the "which AI product should I use?" question partially shifts to "which MCP servers do I need?" The agent is the reasoning layer; MCP servers are the capability layer. The combination of a capable frontier model and a well-configured set of MCP servers can handle an enormous range of professional workflows.

Key Takeaways

• MCP is the open standard (governed by the Linux Foundation's Agentic AI Foundation) that lets any AI agent connect to any tool — adopted by OpenAI, Google, Microsoft, and generating 97 million+ monthly SDK downloads
• The USB-C analogy: MCP standardizes agent-to-tool connectivity the same way USB-C standardized device charging
• MCP's core primitives are Tools, Resources, and Prompts, with Elicitation handling mid-task human input; Sampling still works but was deprecated in the July 2026 spec
• The July 28, 2026 spec removed the session handshake and made every request self-contained, so a remote MCP server can finally scale behind an ordinary load balancer — the change that unblocked enterprise deployment
• Project instruction files (CLAUDE.md, AGENTS.md, copilot-instructions.md) complement MCP by giving agents project-specific knowledge that makes them immediately effective in your codebase