What Is MCP (Model Context Protocol) and How It Works

June 23, 2026 · updated June 25, 2026 · How Claude Actually Works (part 7)

▶ Watch on YouTube & subscribe to The Stack Underflow

Before USB-C, every device had its own proprietary cable drawer. The situation for AI tools in 2023 was exactly the same: every team wiring GitHub, Notion, Jira, or their internal APIs into a new AI application had to write a custom adapter — from scratch, differently each time. Three apps and three tools meant nine connectors to write, test, maintain, and update whenever an API changed. Ten apps and twenty tools meant two hundred. This is what engineers call the N×M matrix, and it scales catastrophically.

MCP (Model Context Protocol) is Anthropic’s answer to that problem, released in November 2024 and since transferred to the neutral Agentic AI Foundation (AAIF) under the Linux Foundation (Anthropic, Block, and OpenAI co-founded it, treating MCP the same way the web treats HTTP). By June 2026, the ecosystem had crossed 10,000 public servers, 97 million monthly SDK downloads, and adoption by ChatGPT, Cursor, Gemini, and Microsoft Copilot. It is, deliberately, the most important boring standard in AI right now.

The one-sentence version: MCP is an open protocol that turns an N×M integration problem — every app re-wires every tool — into an N+M problem: each tool ships one MCP server, each app ships one MCP client, and the protocol connects them at runtime.

The Integration Problem: N×M Becomes N+M

Without a shared standard, every application that wants to call an external tool writes a bespoke adapter. The coupling is total: app A needs its own GitHub connector, its own filesystem connector, its own database connector. So does app B. So does app C.

WITHOUT MCP                          WITH MCP
────────────────────────────         ─────────────────────────────────────
App A ──── custom ──── GitHub        App A ─┐
App A ──── custom ──── Slack         App B ─┤── MCP ──── GitHub MCP Server
App A ──── custom ──── DB            App C ─┘        ── Slack  MCP Server
App B ──── custom ──── GitHub                        ── DB     MCP Server
App B ──── custom ──── Slack
App B ──── custom ──── DB
App C ──── custom ──── GitHub        3 clients + 3 servers = 6 integration units
App C ──── custom ──── Slack         (vs. 9 custom connectors)
App C ──── custom ──── DB

9 bespoke connectors

MCP collapses the matrix. Each tool author writes one MCP server. Each application author writes one MCP client. They connect at runtime through a shared protocol — no custom glue per pair required. At org scale, the savings are not incremental; they are structural.

The Three Roles

Every MCP deployment involves three concrete roles. Understanding them prevents the most common architecture mistakes.

The client is what you build your agent in. The server is the bridge to the tool’s real API. The client speaks MCP; the server translates between MCP and whatever proprietary protocol the underlying tool uses. That translation lives in one place, written once, reused by every client.

┌──────────────────────┐        MCP (JSON-RPC)       ┌─────────────────────┐
│   HOST / CLIENT      │ ◄──────────────────────────► │    MCP SERVER       │
│  (Claude Code, your  │                               │  (wraps one tool)   │
│   custom agent)      │                               └─────────┬───────────┘
└──────────────────────┘                                         │ native API
                                                       ┌─────────▼───────────┐
                                                       │    RESOURCE         │
                                                       │  (DB / API / files) │
                                                       └─────────────────────┘

What an MCP Server Exposes

Every MCP server can offer up to three categories of capability, each serving a distinct purpose in the agent’s reasoning cycle.

Tools are callable actions the model can invoke. Each tool has a name, a description written for the model to read, and a JSON Schema that describes its arguments. The model sees the descriptions when it is deciding what to do, picks the right tool, and the client executes the call. Tools are the most commonly used primitive — they are what makes agents act.

Resources are readable blobs of context. Think files, URIs, data blobs, database snapshots. The model does not call resources directly; the client reads them and decides whether to attach them to the conversation context. Resources feed information into the context window without burning a tool-call round trip.

Prompts are reusable templates the server ships that the client can surface to users. Slash commands, scaffolded workflows, structured conversation starters. The server is the vendor of capability; the client decides how to expose it in its UI.

Discovery: The Dynamic Tool Menu

This is one of MCP’s most practically useful properties. On startup, the client sends a tools/list request over JSON-RPC 2.0. The server replies with a structured menu of tool descriptors — names, descriptions, schemas. The client populates its tool list from that response.

Client                               MCP Server
  │                                       │
  │── tools/list ────────────────────────►│
  │                                       │
  │◄─── [{name:"read_file", ...},         │
  │      {name:"write_file", ...},        │
  │      {name:"list_dir",  ...}] ────────│
  │                                       │
  │  (client registers these tools        │
  │   in the model's available-tools      │
  │   list for this conversation)         │

The payoff: tools are discovered at runtime, not hard-coded in client code. You add a new tool to the MCP server, restart the client, and it just appears — no client-side deployment, no code change, no recompile. The tool menu lives in the server.

Transports: The Load-Bearing Detail

Transport is the mechanism by which the client and server exchange JSON-RPC messages. Getting this wrong costs you days. MCP currently has two supported transports and one deprecated one.

stdio (Standard IO)

The client launches the MCP server as a child process and communicates over stdin/stdout. No network, no ports, no TLS configuration, no OAuth dance.

Use it for: local, single-user setups — developer tooling on your machine, filesystem access, anything that does not need to be reached over a network. Claude Code uses stdio for local MCP servers by default.

Streamable HTTP

One HTTP endpoint that accepts both POST (for client-to-server requests) and GET (for server-to-client streams). Stateless by design — the 2026 spec revision formally standardized stateless session handling so these servers run cleanly behind round-robin load balancers and serverless infrastructure without sticky sessions or a shared session store.

Use it for: remote, cloud-hosted MCP services, production multi-tenant deployments, anything that needs to be reached over a network by multiple clients.

HTTP + SSE (Deprecated — do not use for new work)

Two separate endpoints: one for POST, one for a dedicated SSE stream. This was deprecated in the MCP spec dated 2025-03-26 because two endpoints created routing problems with load balancers and serverless platforms. Major vendors set migration deadlines through mid-2026. Any tutorial recommending HTTP + SSE for new work is out of date. Start with Streamable HTTP for all remote deployments.

Secrets and Configuration

Your MCP config file (mcp.json or equivalent) references secrets by name, not by value. The client expands environment-variable references at launch time — the file you commit to version control contains no real credentials.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

The pattern ${GITHUB_TOKEN} is expanded from your shell environment. This is the standard pattern across the MCP ecosystem — configure the name in the file, inject the secret through environment variables, keep the two layers separate.

The Payoff: One Server, Every Client

Write one GitHub MCP server. Connect it to Claude Code, your custom agent built with the Anthropic SDK, and any other MCP-aware client. Same protocol, same tool descriptions, same prompts — every client lights up without you writing any additional integration code.

                    ┌──────────────────────┐
                    │  GitHub MCP Server   │
                    │  (written once)      │
                    └──────┬───────────────┘
                           │ MCP protocol
           ┌───────────────┼───────────────┐
           │               │               │
    ┌──────▼─────┐  ┌──────▼─────┐  ┌─────▼──────┐
    │ Claude     │  │ Agent SDK  │  │ Your       │
    │ Code       │  │ custom app │  │ web app    │
    └────────────┘  └────────────┘  └────────────┘

One thing MCP does not change: each tool call is still a single request-response. The model asks, the tool answers. To get iterative, multi-step behavior — where the model loops, uses tool results to inform the next decision, and keeps going until a goal is met — you need an agent loop on top of MCP. That is exactly where the next episode picks up.

Common Misconceptions

“MCP is specific to Claude.” MCP is an open protocol, now governed by the Agentic AI Foundation under the Linux Foundation. ChatGPT, Cursor, Gemini, Windsurf, and Microsoft Copilot all support it. The underlying model is irrelevant to the protocol.

“MCP replaces function calling.” MCP is a transport and discovery protocol. Tool definitions still follow the same name/description/JSON-Schema shape they always have. MCP standardizes how those tools are surfaced and called across different clients — not the format of the call itself. Function calling and MCP are complementary, not competing.

“HTTP + SSE is still fine for production.” It was deprecated in March 2025. Streamable HTTP is the correct choice for any new remote deployment. The two-endpoint design created session affinity requirements that do not survive modern cloud infrastructure.

“Adding a new tool requires updating the client.” Discovery is dynamic. Modify the server, restart the client, and the new tool appears via tools/list. The client code does not need to know about any specific tool in advance — that knowledge lives in the server’s tool descriptors.

Frequently Asked Questions

Can I use MCP without Claude Code specifically?

Yes. The MCP client role can be filled by any host that implements the protocol — Claude Code, the Claude Desktop app, Cursor, custom agents built with the Anthropic SDK, or agents using entirely different model providers. Claude Code is Anthropic’s reference implementation and the most fully-featured host, but it is one example among many.

What is the difference between a tool and a resource in MCP?

Tools are actions — the model can invoke them and get a response: read a file, open a pull request, run a SQL query. Resources are readable context — the client pulls them in and decides whether to include them in the model’s context window. The model never calls a resource directly; the client does. If you want the model to be able to trigger a retrieval, use a tool. If you want to inject ambient context, use a resource.

When should I use stdio vs. Streamable HTTP?

Use stdio when the MCP server runs locally on the same machine as the client and does not need to be reached over a network — typical for developer tooling and local filesystem operations. Use Streamable HTTP when you are hosting the server remotely, need to serve multiple users, or are deploying to cloud infrastructure. Do not use HTTP + SSE for new implementations; it is deprecated.

Do I need to restart the agent every time I add a new tool to an MCP server?

You need to restart the client so it re-runs the tools/list discovery request and picks up the new descriptor. But you do not need to change or redeploy the client’s own code — the update lives entirely in the server. This is the ecosystem payoff: tool authors ship new capabilities by updating their server, and every client upgrades automatically on next start.

What does it mean that MCP is now “stateless” in the 2026 spec?

The 2026 release candidate (finalizing July 28, 2026) removes session-level state from the Streamable HTTP transport. Previously, a remote MCP server needed sticky routing to keep a client attached to the same server instance. The new spec carries protocol version, client identity, and capabilities in a _meta object on every JSON-RPC request, so any server instance can handle any request. This makes MCP servers first-class HTTP services — round-robin load balancers, serverless functions, and horizontal auto-scaling all work without special infrastructure.

Is MCP the same as the Agent-to-Agent (A2A) protocol?

No. MCP connects a client (an agent or app) to tools (external services and data). A2A (Agent-to-Agent) is a separate protocol for connecting agents to each other — enabling one agent to delegate tasks to a specialized peer. They solve different problems and are designed to be complementary in a multi-agent architecture.

Where This Fits in the Series

This tutorial is part of How Claude Actually Works, a course that builds from token mechanics all the way through multi-agent production systems. If you have not read The Claude Stack Mental Model, start there — it frames where MCP sits in the overall architecture (Layer 2: Reach).

The previous episode, How Claude Uses Tools, covers the mechanics of a single tool call: how the model decides to call a tool, how the JSON schema shapes the request, and how the result feeds back into the context. This episode shows how MCP standardizes tool discovery and transport so you write the wiring once.

The next episode, How Claude Code Works: The Agent Loop, takes a single MCP tool call and turns it into a reasoning-and-acting cycle — the foundation of everything in the series that follows.

For a broader view of where MCP, hooks, skills, and subagents fit together, see Claude Stack: MCP, Hooks, Skills, and Subagents Overview.

Browse all tutorials to follow the full sequence.