Free to read. Sign up to save your progress and pick up where you left off.

Sign up free
10 min read·Updated August 28, 2026

Model Context Protocol (MCP)

MCP is the open standard that lets any AI agent connect to any tool or data source — ending the fragmented ecosystem of one-off integrations and enabling the truly composable AI stack.

Share

Listen to this lesson

Free preview · first 0:30
0:00 / 0:30

Unlock audio and more

Audio streaming, downloadable PDFs and certificates come with Plus and Pro.

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 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).

💡Key Concept

The USB-C analogy: Before USB-C, every device had its own charging connector — a different cable for your phone, laptop, headphones, and camera. USB-C standardized the connector so any cable works with any device. MCP is USB-C for AI agents: any MCP-compatible agent can connect to any MCP server, regardless of who built either one.

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.

⚠️Warning

If you maintain an MCP server, three things are now on a clock. Roots, Sampling, and Logging are deprecated, as is the legacy HTTP-plus-server-sent-events transport. All four keep working for at least twelve months, but they are on an announced off-ramp — the July 2026 spec also introduced a formal deprecation policy, so this is the first change that comes with a published timeline rather than a surprise. Tools, Resources, Prompts, and Elicitation are unaffected.

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

🎯Tip

Finding MCP servers: The best directories are mcp.so, Smithery.ai, Glama.ai, and the Awesome-MCP GitHub list. Most major services also publish official MCP servers in their documentation.

For developers:

ServerWhat It Enables
GitHub MCPRead issues, create PRs, search repos, manage branches
File system MCPRead/write any file outside the IDE's native view
Postgres/Supabase MCPNatural language database queries; schema inspection
Playwright/Puppeteer MCPAutomated browser control and web scraping
Vercel MCPDeploy, check logs, manage environment variables
Docker MCPManage containers, inspect logs

For productivity:

ServerWhat It Enables
Slack MCPSearch messages, send notifications, read channels
Notion MCPRead and update Notion pages and databases
Google Drive MCPRead documents, search Drive, create files
Calendar MCPRead/create events, check availability
Email MCPDraft and send emails, search inbox

For enterprise:

ServerWhat It Enables
Salesforce MCPQuery CRM data, update records, manage opportunities
Jira/Linear MCPCreate issues, update status, search tickets
Snowflake/BigQuery MCPQuery analytics data warehouses

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.

🎯Tip

Invest in AGENTS.md early. A well-written AGENTS.md file takes 30-60 minutes to create. It pays back on every subsequent agent session — fewer wrong assumptions, fewer requests for clarification, faster completion of tasks.

What Comes Next: the Roadmap

The July spec fixed how MCP scales. The roadmap published by core maintainers David Soria Parra and Den Delimarsky sets out what the next releases are aimed at, and it points somewhere different — at what an agent is actually allowed to do. Five priorities, no dates attached:

  • Agentic messaging primitives. Tasks, subscriptions and progress notifications expand so a call can be a long-running, streamed job that you steer while it runs, rather than a quick request-and-response. This is the protocol catching up with how agents are really used.
  • Agent identity and enterprise security. The substantive one. Workload identity federation and proof-of-possession would let one agent delegate to another without handing over an API key. Today, agent-to-agent delegation usually means passing a long-lived credential, which is exactly the pattern security teams refuse to approve — so this is the item most likely to decide whether MCP gets into regulated environments.
  • HTTP-native transport unification. One transport story across deployment modes, including local servers, instead of a separate local path.
  • Improved primitives. Standardized tool-result handling, plus progressive discovery so an agent can work against a large tool catalog without loading all of it up front.
  • Software development kit experience. Better ergonomics, conformance testing and documentation across languages.

📝Note

Read the sequence, not just the list. Sessions removed in July, identity and delegation next: the protocol is being hardened for multi-agent systems inside organizations that have security review. If you are choosing whether to build on MCP, that trajectory matters more than any single feature on the list.

The Physical-World Sibling: the Model Hardware Standard

On August 27, 2026, Anthropic opened a research preview of the Model Hardware Standard (MHS), which does for laboratory and factory equipment roughly what MCP did for software tools. The problem it names is the same one MCP started from. Connecting an agent to a microscope, a liquid handler or a robotic arm currently means writing a bespoke integration for that specific instrument, so every device is a separate engineering project and none of the work transfers.

MHS borrows the shape of a device driver. Hardware describes itself in a standard format and exposes a small set of primitives — read and write — so an agent can discover what is attached and operate it without knowing the vendor in advance. If MCP made software capabilities pluggable, MHS is the attempt to make physical ones pluggable too.

The launch partners are research-heavy rather than industrial: Genentech, Carnegie Mellon, two University of Washington protein-design labs, the HHMI Janelia Research Campus, the quantum computing firm QuEra, and Tetsuwan Scientific. On the vendor side, Amazon Web Services, Tecan, Universal Robots and QIAGEN are building support.

⚠️Warning

Preview, not a standard you can adopt yet — and the safety model is the interesting part. MHS is not open source and access is limited to selected partners, so treat it as a signal about direction rather than something to build on today. Two design choices are worth noting regardless of whether you ever use it. Drivers enforce device-level safety limits in the driver itself rather than trusting the model to stay in range, and high-risk actions can require a person to approve them before they execute. Anthropic is explicit that current models have a poor grasp of physical and chemical constraints — which is the honest reason those limits live in the hardware layer instead of the prompt.

The reason this belongs in a lesson about MCP is the pattern rather than the product. A capability becomes broadly useful to agents once someone writes the boring interface layer that makes every instance of it look the same. Expect the same move wherever agents are asked to act on something that was not designed for them.

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
  • The published roadmap points next at agent identity — workload identity federation and proof-of-possession, so one agent can delegate to another without passing an API key, which is the change most likely to make MCP viable inside security-reviewed enterprises
  • 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
  • The Model Hardware Standard, opened as a research preview on August 27, 2026, applies the same driver pattern to laboratory and factory equipment so agents can operate instruments without a bespoke integration each time — with safety limits enforced in the driver and human approval required for high-risk actions, because current models reason poorly about physical constraints

Save your progress & keep learning

Sign up free to bookmark lessons, track which modules you've completed, and get an alert whenever a lesson you saved gets a major update.

Key Terms in This Lesson

🧭Recommended for you

Optional detours — these connect to what you just read, and your next lesson will be waiting.