MCP Explained (For People Who Just Want More)

MCP, the Model Context Protocol, is an open-source standard for connecting AI applications to external systems. A small program called an MCP server exposes a fixed set of actions; your agent calls them the way it calls any other tool, and the server does the actual work.

Updated August 2026: MCP is no longer one company's announcement. Its GitHub organization states that the project is hosted by The Linux Foundation and open to contributions from the entire community, and publishes SDKs in ten languages alongside the specification. Claude, ChatGPT, VS Code and Cursor all speak it natively, which is why it is worth understanding on its own terms and not just as a Claude Code feature.

What is MCP?#

MCP is a set of rules, not a product, for how an AI application talks to an outside program. One side runs an MCP client inside the AI app (Claude Code, Claude Desktop, Cursor); the other runs an MCP server exposing tools, data ("resources"), or reusable prompt templates. The official site's analogy is a USB-C port for AI applications: one standard connector instead of a different cable for every device.

The "client" part is invisible to you as a user. Every time you connect a server, the AI app quietly opens a dedicated client for it behind the scenes, so a session with five servers connected is really running five separate client-server conversations at once. What differs server to server is mostly where it runs and how the two sides reach each other:

All four carry the same message format underneath; only the pipe differs. The status column comes from Claude Code's MCP documentation, which states plainly that the SSE transport is deprecated and that HTTP servers should be used where available.

What problem does it solve?#

Before MCP, every agent-to-tool connection was a one-off integration — a custom plugin for Slack, another for GitHub, another for your database, each written to one AI app's own format. MCP standardizes that connection once: any MCP-speaking agent can use any MCP server without custom glue code.

That's the practical shift underneath the "give it hands" framing: instead of every AI application building its own bespoke connector for every tool it wants to reach, tool builders write one server against a shared spec, and every MCP-compatible application can use it immediately. It's the same logic that gives one USB-C cable a shot at charging your laptop, your headphones, and your phone.

The scale of that is visible in the protocol's own repositories: the MCP organization publishes the specification, SDKs for TypeScript, Python, Java, Kotlin, C#, Go, PHP, Ruby, Rust and Swift, an Inspector for testing servers, and a reference servers repository. Ten language SDKs is what "write the connector once" looks like in practice. This is one piece of the wider vibe coding workflow: describing what you want and generating it is only half the loop, and MCP is largely what lets the look-at-it-and-react half reach outside the chat window — the subject of the pillar on visual feedback for AI coding agents.

What does a server actually do?#

A server does three things on every tool call: it validates the request against the JSON Schema it declared for that tool, it does or delegates the actual work — reading a file, hitting an API, controlling a local app — and it hands the result back as a plain content block Claude can read, usually just text or JSON.

Here's what that looks like end to end, drawn from a real, shipping MCP server built for a desktop app. The server is a short script the AI app launches as a subprocess over stdio. It imports an MCP SDK that supplies two building blocks — a server object and a transport — so the developer's own job is just registering tools; none of the JSON-RPC wiring is hand-rolled.

Each tool registration is three pieces: a name Claude will call it by, a description written for the model, not the person using it (Claude reads that text to decide whether this tool is the right one for the current request), and a schema for its inputs, usually written with a validation library instead of hand-typed JSON Schema.

In the server this section is grounded in, that pattern repeats five times: start a recording, stop it, check whether one is running, list past recordings, and fetch a finished recording's write-up. None of those five handlers does the underlying work itself. Each one reads a small file the desktop app writes to disk, containing a local port number and an access token, and — if that file exists — makes an authenticated request to the app's own local API and returns the JSON response as a text block. If the file is missing, the tool returns a plain sentence saying the app isn't open, instead of a raw connection error the model would have to interpret on its own.

Strip away the specifics and almost every MCP server does the same four things:

1. Declares its tools — name, description, and input schema — when a client connects.
2. Waits for a tools/call request naming one of them.
3. Validates the input, then does the work directly or forwards it to whatever system it fronts.
4. Returns the result as a content block — text, an image, or a resource link — that the model reads like any other tool output.

How do you install one?#

Installing an MCP server usually takes one command and, for anything you didn't build yourself, an approval step. In Claude Code, claude mcp add registers a remote server by URL or a local one by the command that starts it; you then pick where the configuration lives: your own project, shared with your team, or every project on your machine.

1. Pick a server. Remote, reachable over HTTP, or local, running as a process your machine starts.
2. Add it with one command. claude mcp add --transport http <name> <url> for a remote server, or claude mcp add --transport stdio <name> -- <command> for a local one. Other AI apps use their own equivalent — a settings panel or a JSON config file that means the same thing.
3. Choose a scope. Local (this project only, private to you, the default), project (checked into the repo and shared with your team), or user (every project on your machine).
4. Approve it. Claude Code prompts for approval in interactive sessions before using project-scoped servers from a .mcp.json file, and claude mcp reset-project-choices clears those decisions if you change your mind.
5. Confirm it connected. claude mcp list shows a health status next to each server — Connected, Needs authentication, or Failed to connect — so a broken server does not fail silently in the background.

What can go wrong?#

MCP servers run with real permissions, and Claude decides when to call them, so most problems are trust and scope, not the protocol itself. A local stdio server runs as a process with whatever access you gave it. A tool's description can mislead the model into calling it wrongly. Claude Code asks for approval before running a server you didn't set up yourself.

A few specific failure modes are worth knowing before you go install ten servers at once:

• Over-scoped access. A filesystem server pointed at your whole home directory can do more than the task needs; pointing it at one project folder is the safer default.
• Descriptions are untrusted input, too. The model reads a tool's description to decide when to call it, so a poorly or maliciously written description can talk it into calling that tool when it shouldn't — not a hypothetical, just the reason project-scoped servers get an approval prompt.
• Auth, not the protocol, usually breaks first. A remote server's OAuth token or bearer credential expires or gets revoked; a "failed" status in your server list is almost always that, not a bug in MCP itself.
• Local processes can just crash. A stdio server is a normal program; if it dies, nothing about MCP resurrects it. Claude Code reconnects HTTP and SSE servers automatically with exponential backoff, up to five attempts, but stdio servers are not reconnected — which is why checking connection status after any change is worth the ten seconds.
• A chatty server eats your context. Claude Code's cost guidance notes that MCP tool definitions are deferred by default, so only tool names enter context until a tool is used, and that a single tool result is capped at 25,000 tokens with a warning above 10,000. A server that returns everything it knows is a real budget line, not a rounding error.

What's worth installing first?#

Start with something that removes real copy-pasting from your day: a filesystem or Git server so Claude can read your repo directly, GitHub for issues and pull requests, and a web-fetch server for pulling in a page instead of pasting it in. Add narrower tools once you know what you keep re-explaining by hand.

A reasonable starter set:

• Filesystem — the agent reads and writes files in a folder you specify directly, instead of you pasting code back and forth.
• Git or GitHub — it sees commit history, opens issues, and reviews pull requests on its own.
• A web-fetch or search server — it pulls in a page instead of you copying the text over by hand.
• Slack — worth it once a meaningful share of your context lives in channel history.
• Whatever database you already query by hand — Postgres and similar servers exist for exactly this.

Add narrower tools once a real gap shows up. One example built on exactly the request-and-bridge pattern described earlier is Walkie, a screen-and-voice recorder for reviewing AI-generated code: its MCP server exposes tools to start a recording, stop it, check status, list past recordings and fetch a finished review, each forwarding to the desktop app's own local API. If you are weighing that kind of feedback tool against the alternatives, the priced comparison of agent feedback tools covers where it fits and where a free screenshot is still the better answer, what is inside a REVIEW.md bundle documents the format it hands back, and screen recording for Claude Code covers the capture side.

The fastest way to understand any of this is to install one server and watch what changes. Open your AI app's MCP settings, add the filesystem server for a project you're already in, and ask it to do something that used to mean pasting a file into chat. Everything else here is detail on top of that one loop.