MCP explained: the USB-c for AI tools

Think of the host as the laptop. It is the thing with the USB-C port.

The client

The client is a small connector that lives inside the host and manages one connection to one server. The host spins up a separate client for each server it talks to. If Claude Desktop connects to your wiki and your calendar, that is two clients, each keeping a clean, isolated channel open.

You rarely touch the client directly. It is plumbing the host manages for you. Think of it as the USB-C controller chip: invisible, but it enforces the protocol on the host's side.

The server

The server is where the interesting work happens. An MCP server is a standalone program that exposes capabilities to the host: tools it can call, resources it can read, and prompts it can use. You write servers (or install ones others wrote) to connect Claude to your actual systems.

The server is the device on the other end of the cable: a wiki, a database, a GitHub repo, a ticketing system.

The flow is always the same. Host launches a client. Client connects to a server. Server advertises what it can do. The model, running in the host, decides when to call those capabilities, and the client relays the request.

What a server actually exposes

An MCP server speaks in three nouns. Learn these and you can read any server's source.

• Tools: actions the model can invoke, like search_wiki or create_ticket. These are functions with typed inputs. The model chooses to call them.
• Resources: data the host can read, like a specific wiki page or a file. Think read-only context the user or model pulls in.
• Prompts: reusable prompt templates the server offers, like a "summarize this incident" workflow the user can trigger.

Most servers you build will lean heavily on tools. That is where the leverage is.

A concrete example: exposing your team wiki to Claude

Say your team runs an internal wiki. Engineers keep forgetting where the on-call runbook lives, and you want Claude to answer "what's our deploy rollback procedure?" by actually searching the wiki, not guessing.

You build an MCP server that exposes one tool: search_wiki. Here it is, using the official Python SDK with the modern FastMCP style.

That is a complete, working server. The @mcp.tool() decorator turns a plain Python function into a capability Claude can call. The docstring is not decoration: the host sends it to the model so Claude knows *when* to reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → for this tool. The type hints (query: str, limit: int) become the input schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → the client validates against.

Notice what you did not do. You did not write anything Claude-specific. You did not parse the model's output or format tool-call JSON by hand. The protocol handles all of that. If your colleague uses a different MCP host next year, this exact server still works.

Connecting it to Claude desktop

To make Claude Desktop (a host) load your server, you register it in the host's MCP config file. On a developer machine it looks like this:

Restart the host, and Claude now sees search_wiki in its toolbox. Ask "what's our rollback procedure?" and Claude decides to call the tool, the client relays the request to your server, your server queries the wiki, and the snippets flow back into the conversation as grounded context.

This is the same pattern behind the Connectors you see in the Claude apps and the connector marketplace: pre-built MCP servers for common tools (Google Drive, GitHub, and more) that you enable with a click instead of editing a config file. Under the hood, a marketplace connector and your hand-rolled wiki server are the same kind of thing.

Transports: local vs remote

How does the client actually talk to the server? MCP defines two main transports, the channel the messages travel over.

• stdio: the host launches the server as a local subprocess and talks to it over standard input/output. This is what the config above uses. Great for local tools and development.
• Streamable HTTP: the server runs as a remote web service and the host connects over HTTP. This is how hosted connectors and team-wide servers work, where you do not want every employee running a Python process on their laptop.

For your wiki server, stdio is perfect while you build. When you are ready to share it across the team, you redeploy the same logic behind an HTTP endpoint and point everyone's host at the URL.

Where MCP fits in the wider Claude ecosystem

MCP is the connective tissue, but it is worth seeing how it relates to the other building blocks you will use.

The Claude Agent SDK is for building autonomous agents in code. When that agent needs to touch external systems, it uses MCP servers as its tools. So MCP is not a competitor to the Agent SDK; it is the standard the SDK uses to plug into the world. The same is true of Claude Code: you can add MCP servers to Claude Code so it can search your issue tracker or query a database while it works.

Skills are a different layer. A Skill packages instructions, scripts, and resources that teach Claude *how* to perform a procedure well. MCP is about *connectivity* (reaching a system); Skills are about *capability* (knowing how to do a task). A well-designed setup often uses both: a Skill that describes your incident-response process, calling MCP tools that read your monitoring dashboards.

The Messages API is the low-level surface. If you build your own host from scratch, you handle the model calls there and wire MCP into your own client logic. Most teams do not need to go this deep, but it is good to know the layering. The official docs at docs.claude.com cover the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →, the Agent SDK, and connectors in detail, and github.com/anthropics has the SDKs and reference servers.

The mental model: MCP standardizes the *port*, the Agent SDK and Skills decide *what you do once connected*, and the Messages APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → is the *engine* underneath.

Security: the part people skip

A USB-C port can charge your phone or wipe your drive depending on what is plugged in. MCP is the same. A server you install runs with whatever access you give it, and the model can decide to call its tools.

Three habits keep you safe:

1. Only install servers you trust. A malicious server can exfiltrate data or take destructive actions. Treat a third-party MCP server like any other dependency you would audit.

2. Scope server permissions tightly. Your wiki server should have a read-only APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → tokentokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.View full definition →, not admin credentials. If a tool only needs to search, do not give it the ability to delete.

3. Keep humans in the loop for destructive tools. Hosts like Claude Desktop prompt for approval before running tools. Do not disable that for anything that writes or deletes.

The protocol gives you reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition →. You are responsible for the blast radius.

Why this is a big deal

The quiet win of MCP is composability. Once your wiki, your ticketing system, and your monitoring all speak MCP, you can mix and match them across hosts without rewriting anything. A new AI app launches with MCP support, and your existing servers light up inside it on day one.

That is the USB-C promise made real for AI: build the connector once, plug it in everywhere.

Key Takeaways

• Memorize the three roles. Host (the AI app the user touches), client (the per-connection manager inside the host), server (the program exposing tools, resources, and prompts). Every MCP setup is some arrangement of these.
• Start with one tool, locally. Write a small server with FastMCP, expose a single well-documented tool, register it in your host's config over stdio, and confirm Claude calls it before adding more.
• Write docstrings for the model, not for humans. The tool description is what Claude reads to decide when to call your tool. Vague docstrings cause missed or wrong tool calls.
• Scope credentials to least privilege and keep approvals on. A read-only tokentokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.View full definition → and human-in-the-loop confirmation are your main defenses, since the model, not you, decides when tools fire.
• Remember the layering. MCP is the standard port; the Agent SDK and Skills decide what you do once connected. Reach for the right layer instead of rebuilding connectivity yourself. Start at