MCP Explained: How AI Agents Connect to Any Tool

June 23, 2026 · updated June 25, 2026 · AI Agent Internals: How Coding Agents Really Work (part 2)

▶ Watch on YouTube & subscribe to The Stack Underflow

Before MCP existed, every AI editor had to write custom integration code for every external tool. Cursor talking to GitHub was one bespoke connector. VS Code talking to the same GitHub API was a completely different one. Multiply three editors by five tools and you have fifteen integrations to write, test, and maintain — and each new tool meant another round of bespoke work for every editor team.

The Model Context Protocol (MCP), open-sourced by Anthropic in November 2024 and governed since 2025 under the Linux Foundation’s Agentic AI Foundation (AAIF), solves that combinatorial problem with a single shared protocol. Any host that implements MCP once can connect to any tool server that implements MCP once. By mid-2026 that proposition had been validated at scale: the public registry crossed 9,400 distinct MCP servers, and combined Python and TypeScript SDK downloads hit 97 million per month (modelcontextprotocol.io, 2026).

The one-sentence version: MCP defines a standard three-role architecture — host, client, server — so that one AI editor can talk to every tool, and one tool server can work with every editor, without anyone writing custom glue code.

The problem: N times M

The combinatorial explosion is the clearest way to see why a standard protocol matters.

Before MCP — N editors × M tools = N×M integrations:

  Cursor       ──── custom code ────▶  GitHub API
  Cursor       ──── custom code ────▶  Postgres
  Cursor       ──── custom code ────▶  Linear
  VS Code      ──── custom code ────▶  GitHub API
  VS Code      ──── custom code ────▶  Postgres
  VS Code      ──── custom code ────▶  Linear
  Claude Code  ──── custom code ────▶  GitHub API
  Claude Code  ──── custom code ────▶  Postgres
  Claude Code  ──── custom code ────▶  Linear

  3 editors × 3 tools = 9 integrations.
  Add one more tool: 3 more integrations.
  Add one more editor: 3 more integrations.

MCP collapses that to N plus M: each editor implements MCP once, each tool implements MCP once, and the protocol handles the rest.

After MCP — N editors + M tools = N+M implementations:

  Cursor      ──┐
  VS Code     ──┼──▶ MCP Protocol ──▶ GitHub MCP Server
  Claude Code ──┘                └──▶ Postgres MCP Server
                                 └──▶ Linear MCP Server

  3 editors + 3 tools = 6 implementations, not 9.
  Add one more tool: 1 implementation, not 3.

This is the same insight that drove the Language Server Protocol (LSP) in the IDE world — MCP is deliberately modeled on LSP (modelcontextprotocol.io/specification/2025-11-25). LSP standardized how editors support programming languages; MCP standardizes how AI applications integrate tools and context.

The three roles: host, client, server

MCP defines exactly three roles, and the distinction between host and client trips people up constantly.

The relationship to hold in your head: the host contains clients; clients do not contain the host. If your editor is connected to five MCP servers, it is managing five independent clients internally. Each client maintains a single stateful connection to exactly one server. This one-to-one pairing keeps failure domains isolated — a crashed database MCP server kills one client, not the whole host.

┌─────────────────────────────────────────────────┐
│  Host (e.g., Claude Code)                        │
│                                                  │
│  ┌──────────────┐  ┌──────────────┐             │
│  │  Client A    │  │  Client B    │  ...        │
│  │  (GitHub)    │  │  (Postgres)  │             │
│  └──────┬───────┘  └──────┬───────┘             │
└─────────┼────────────────┼────────────────────  ┘
          │                │
     ┌────▼────┐      ┌────▼─────┐
     │ GitHub  │      │ Postgres │
     │ MCP Svr │      │ MCP Svr  │
     └─────────┘      └──────────┘

What servers and clients actually expose

Most explanations stop at “servers expose tools.” The 2025-11-25 spec (modelcontextprotocol.io) is more precise: servers offer three capability types, and clients offer three different capability types back.

Server-side capabilities (what the server offers)

The control axis matters architecturally. Resources are pulled by the host, not autonomously decided by the model. Prompts are user-initiated selections, not model decisions. Only tools are invoked at the model’s discretion, which is why tool grants are the primary attack surface to think about carefully.

Client-side capabilities (what the client offers back)

These are newer and less discussed, but they are what make MCP genuinely suitable for complex agentic workflows:

Sampling is particularly powerful: a server that declares sampling support can hand the LLM a problem, get a completion, and use that completion to drive further tool calls — all coordinated through the host, with the user retaining approval rights over each LLM invocation. Elicitation, added formally in 2025, enables interactive server-side workflows: instead of failing when a required field is missing, the server sends an elicitation request, the host surfaces a dialog, and execution resumes with the user’s input.

The five-step lifecycle

Here is what happens from the moment your editor starts up to the moment a tool result lands back in the model’s context (modelcontextprotocol.io/specification/2025-11-25):

Step 1 — HANDSHAKE
  Client sends initialize request:
    protocol_version, capabilities, client metadata
  Server responds:
    matching protocol version, its own capabilities, server metadata
  Client sends initialized notification.
  (Both parties now know what each can do.)

Step 2 — DISCOVERY
  Client sends: tools/list, resources/list, prompts/list
  Server responds with full capability manifests.
  Host merges tool schemas and forwards them to the LLM.

Step 3 — TOOL CALL
  LLM emits structured tool-call in its output.
  Host routes the call to the correct client.
  Client sends JSON-RPC request to the server.

Step 4 — EXECUTION
  Server runs the logic: queries DB, calls GitHub API, reads a file.
  Real side effects happen here. The model has not run any code.

Step 5 — RESULT
  Server returns result to client.
  Client forwards to host.
  Host appends result to the model's context.
  Loop continues.

Transport: STDIO vs. Streamable HTTP

All MCP communication uses JSON-RPC 2.0 as its message format. The 2025-03-26 spec revision introduced two standard transport modes, and the choice between them is a deployment architecture decision, not a protocol difference.

The Streamable HTTP transport replaced the older HTTP+SSE transport in the March 2025 revision. The key improvement: an Authorization: Bearer header can now be validated on every envelope independently, so standard API gateways, WAFs, and load balancers work without custom middleware. The 2026-07-28 release candidate adds Mcp-Method and Mcp-Name headers so load balancers can route on operation type without inspecting the request body.

From the model’s perspective, transport is invisible. A tool call goes in, a result comes back. Whether the plumbing is a local subprocess or a Cloudflare-fronted remote service is irrelevant to the LLM.

Tool annotations: the risk vocabulary

The 2025-03-26 spec added tool annotations — structured hints that servers attach to each tool declaration to describe its risk profile. Four boolean hints are defined:

Tool: delete_file
Annotations:
  readOnlyHint:    false   -- modifies state
  destructiveHint: true    -- irreversible action
  idempotentHint:  false   -- calling twice differs from once
  openWorldHint:   false   -- operates only within declared roots

Hosts use these annotations to decide whether to auto-approve a tool call or surface a confirmation dialog. A tool from a trusted server with readOnlyHint: true can be auto-approved. A tool with destructiveHint: true should prompt the user.

The critical caveat, explicit in the spec: “tool annotations MUST be considered untrusted unless they come from a trusted server.” A malicious MCP server can lie in its annotations. Annotations are a usability signal from honest servers, not a security boundary. Security comes from your host’s trust model and tool grants — not from a hint field in a JSON payload.

Practical guidance: how to apply MCP today

1. Choose the right transport for your deployment. For local developer tooling (file system, git, CLI tools), STDIO is simpler and has no network attack surface. For shared infrastructure accessed by a team, Streamable HTTP gives you standard auth, logging, and horizontal scaling.

2. Scope your server’s tool list to what the task actually requires. Every tool you expose is a capability the model can invoke. A documentation-search server does not need a delete_file tool. Applying least-privilege at the tool-declaration level is simpler and more reliable than trying to gate it at runtime.

3. Implement elicitation for interactive server workflows. If your server tool needs a missing credential or a user decision mid-task, elicitation is the right pattern — not failing silently or aborting. The host handles the UI; your server just sends a structured elicitation request and waits.

4. Set tool annotations honestly and completely. Set readOnlyHint: true on all read-only tools, destructiveHint: true on anything that modifies or deletes, and openWorldHint: false on tools that operate only within declared roots. Well-annotated servers integrate better with host UIs and give users accurate risk signals before they approve a call.

5. Verify tool schemas on connection, not just on install. MCP servers can update their tool lists dynamically, and the spec allows servers to notify clients of list changes. A server that was clean at install can change. Build your host to re-validate tool schemas on reconnection, and treat unexpected new tools as requiring fresh user approval (the “rug-pull” attack vector, documented in the OWASP MCP Top 10, 2025).

6. For remote MCP servers, require OAuth-scoped tokens. The 2025-11-25 spec aligns MCP authorization with OAuth 2.0. Use narrow scopes per server, rotate tokens on reconnection, and validate the iss parameter on authorization responses per RFC 9207 (required in the 2026-07-28 release candidate).

Common misconceptions

“The host and the client are the same thing.” The host is the user-facing application — your editor or agent harness. Clients are small internal connectors the host manages, one per server connection. When debugging why a tool call is failing, this distinction tells you where to look: host-level issues affect all tools; client-level issues affect only the tools from one specific server.

“MCP servers only expose tools.” Servers expose three capability types: tools (model-controlled), resources (app-controlled data the host pulls), and prompts (user-selectable templates). And clients expose three capability types back: sampling, roots, and elicitation. The full protocol is bidirectional. Missing the client-side capabilities means missing the human-in-the-loop patterns that make agentic workflows safe.

“MCP requires a remote server.” STDIO servers run as child processes with no network involved. Many MCP servers are local-only command-line programs. Claude Code ships with several STDIO servers out of the box.

“The model executes tools directly.” The model emits a structured output that looks like a tool call. The host is what actually invokes the server. The model never runs code. This is not a footnote — it is the architecture that makes tool-use auditable and controllable: you intercept and gate tool calls at the host boundary, not inside the model.

“Tool annotations are a security boundary.” Annotations are hints from the server about its own behavior. A malicious server can set destructiveHint: false on a tool that deletes your database. Annotations improve UX for trusted servers; they are not a substitute for a host-level trust model and least-privilege tool grants.

Frequently asked questions

What is the relationship between MCP and the orchestrator from episode 1?

They are the same thing from different angles. Episode 1 called the thing that executes tools the “orchestrator.” MCP is the protocol that defines how that orchestrator — now called the “host” — discovers and calls tools through clients and servers. MCP gives the orchestrator pattern a standardized, interoperable implementation.

Do all AI editors support MCP?

Adoption is broad and growing. Claude Code and Claude Desktop are the reference implementations. Microsoft added MCP support to VS Code’s GitHub Copilot agent mode in early 2025. Cursor, Windsurf, and Codex CLI all ship MCP support. OpenAI joined the AAIF governance body in 2025, signaling alignment across the major agent platforms. Because MCP is an open spec, any editor can implement it without permission or licensing.

Can a single host connect to multiple MCP servers simultaneously?

Yes — that is the normal case. The host spins up one client per server. Each client manages its own connection, its own capability list, and its own session state. The host merges all tool schemas before passing them to the model. In Claude Code, you configure multiple MCP servers in ~/.claude/claude_desktop_config.json and all their tools appear as a unified tool list in the model’s context.

What changed in the 2025-11-25 spec versus the earlier versions?

The 2025-11-25 revision is the current stable spec. Key additions over the March 2025 version: the experimental Tasks primitive (any request can return a task handle for async polling), URL-mode elicitation (a server can redirect a user to a browser URL to complete OAuth or credential flows out-of-band), and sampling with tool support (servers can initiate LLM calls that themselves use tools, enabling server-side sub-agent loops). The 2026-07-28 release candidate, the largest revision since launch, moves toward a stateless HTTP core and introduces MCP Apps for server-rendered UIs.

Is JSON-RPC an unusual choice for this protocol?

JSON-RPC 2.0 has been around since 2005. It is deliberately simple: plain JSON requests and responses with a method name and optional params. No binary framing, no specialized tooling needed to debug it — curl and jq are sufficient for testing. The MCP spec chose it for the same reason the Language Server Protocol did: debuggability and zero-dependency implementation in any language.

How does MCP relate to the A2A protocol?

MCP governs agent-to-tool connections: how an agent discovers and calls capabilities. Google’s Agent-to-Agent (A2A) protocol governs agent-to-agent connections: how one autonomous agent delegates to another. They are complementary, not competing. A production multi-agent system uses MCP to wire agents to tools, and A2A (or a similar delegation protocol) to wire agents to agents. See A2A vs MCP Protocols for a full comparison.

Where this fits in the series

This is episode 2 of “AI Agent Internals: How Coding Agents Really Work.” Episode 1 — What Happens When an Agent Uses a Tool — established that the model only produces text and the orchestrator executes tools. This episode explained the MCP protocol that standardizes how tools are discovered and wired up. The next stop is How MCP Apps Work: Tools That Return UI, which covers the MCP Apps extension that lets servers ship interactive HTML interfaces alongside their tool declarations.

For the security angle on what can go wrong when an agent reads untrusted tool results, see Why Your MCP Tools Disappear and the broader multi-agent failure modes in Why AI Agent Projects Fail.

Browse all tutorials to follow the full arc from raw token generation to production coding agents.