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

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

▶ Watch on YouTube & subscribe to The Stack Underflow

Every time a new AI app ships, someone has to wire it to every tool the team depends on — GitHub, Notion, Jira, databases, internal APIs. Do that for three apps and three tools and you’ve got nine custom connectors to write and maintain. Do it at org scale and you’ve got a full-time job that isn’t building anything useful.

MCP (Model Context Protocol) is Anthropic’s answer to that problem. It is a single, open protocol that lets any MCP-speaking client talk to any MCP-speaking tool without custom glue code on every combination. One integration per tool. One integration per client. The matrix collapses.

The one-sentence version: MCP is a standard protocol that turns an N×M integration problem (every app re-wires every tool) into an N+M problem (each app and each tool speaks MCP once).

The Integration Problem MCP Solves

Without a shared standard, every application that wants to call a tool — a file system, a database, an API — has to write a custom adapter. Three apps, three tools: nine connectors. Ten apps, twenty tools: two hundred connectors. This is the classic N×M matrix, and it gets painful fast.

MCP collapses it to N+M. Each tool ships one MCP server. Each client speaks one MCP client. Connect them together at runtime via the protocol — no custom wiring per pair required.

WITHOUT MCP            WITH MCP
─────────────          ─────────────────────────
App A ─┬─ Tool 1      App A ──┐
App A ─┼─ Tool 2      App B ──┤── MCP ──┬── Server for Tool 1
App B ─┼─ Tool 1      App C ──┘         ├── Server for Tool 2
App B ─┼─ Tool 2                        └── Server for Tool 3
App C ─┼─ Tool 1
App C ─┴─ Tool 2
   9 connectors           3 clients + 3 servers = 6 pieces

The Three Roles

MCP defines three concrete roles:

The client is what you write your agent in. The server is the bridge to the tool’s real API. The client speaks MCP; the server speaks MCP on one side and the tool’s native API on the other.

What an MCP Server Exposes

Every MCP server can expose up to three categories of capability:

Tools — callable actions the model can invoke. Each tool has a name, a description, and a JSON schema that defines its arguments. These are identical in shape to the tools described in the previous episode of this series. The model sees the descriptions and decides when to call them.

Resources — readable things the client can pull in as context. Think files, URIs, data blobs. The model does not call resources directly; the client reads them and decides whether to attach them to the conversation context.

Prompts — reusable templates the server ships that the client can surface to the user. Slash commands, scaffolded workflows, pre-structured conversations. The server is the vendor of capability; the client decides how to expose it.

Discovery: How Clients Learn What Tools Exist

On startup, the client sends a tools/list request over JSON-RPC. The server replies with a menu of tool descriptors. The client populates its tool list from that response.

The payoff of this design: you can add a tool to the server, restart the client, and the new tool just shows up — no client-side deployment needed.

Transports: The Load-Bearing Detail

This is where developers lose a week if they get it wrong. 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 OAuth dance.

Use it for: local, single-user setups — your laptop, filesystem tools, anything that doesn’t need to be reached over a network.

Streamable HTTP

One HTTP endpoint that accepts both POST and GET. The server can stream responses back over the same connection. Stateless, so it plays nicely with load balancers and serverless deployments.

Use it for: remote, cloud-hosted MCP services, production deployments, anything multi-tenant.

HTTP + SSE (Deprecated — do not use)

Two separate endpoints: one for POST, one for a server-to-client SSE stream. This was deprecated in the MCP spec dated 2025-03-26 because two endpoints did not play nicely with load balancers or serverless infrastructure.

Major MCP servers have published migration deadlines — Atlassian and Robocorp: June 30, 2026; Copilot (GitHub): April 1, 2026. If you see a tutorial using HTTP + SSE, that tutorial is out of date. New implementations should use Streamable HTTP.

Secrets and Configuration

Your MCP config file (mcp.json or equivalent) references secrets by name, never by value:

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

The client expands ${GITHUB_TOKEN} from your shell environment at launch time. The file you commit to version control contains no real secrets.

The Payoff

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

One thing MCP does not change: each tool call is still a single request-response. The model asks, the tool answers, done. To get iterative, multi-step behavior you need an agent loop on top of MCP — which is exactly where the next episode picks up.

Common Misconceptions

• “MCP is specific to Claude.” It is not. MCP is an open protocol. Any client that implements it can talk to any server that implements it, regardless of the underlying model.
• “MCP replaces function calling / tool use.” It does not. MCP is a transport and discovery protocol. Tool definitions still follow the same name/description/JSON-schema shape. MCP standardizes how those tools are surfaced and called — not the format of the call itself.
• “HTTP + SSE is still the right way to deploy remotely.” It was deprecated in March 2025. Use Streamable HTTP for anything you’re deploying today.
• “Adding a tool requires redeploying the client.” Discovery is dynamic. You update the server, restart the client, and the new tool shows up via tools/list. The client doesn’t need to know about it in advance.

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 other frameworks. Claude Code is just one example of a host.

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 PR, run a query). Resources are readable context — the client pulls them in and decides whether to include them in the model’s context window. Resources are not directly invokable by the model.

When should I use stdio vs. Streamable HTTP?

Use stdio when the server runs locally on the same machine as the client and you do not need network access — typical for developer tooling and local file system operations. Use Streamable HTTP when you are hosting the MCP server remotely or need to serve multiple users.

Do I need to restart my 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 tool descriptor. But you do not need to change or redeploy the client’s own code — the update lives entirely in the server.

Where This Fits in the Series

This tutorial is part of How Claude Actually Works, a course that builds up from how Claude processes tokens all the way through tool use, agents, and multi-model systems. The previous episode introduced tool use (function calling); this episode shows how MCP standardizes tool discovery and transport so you write the wiring once. The next episode covers agent loops — where you take a single MCP tool call and turn it into a reasoning-and-acting cycle.

Browse all tutorials to follow the full sequence.