MCP servers: the USB-C port for AI tools and data

The anatomy-of-an-agent-framework post named MCP as one of the five parts every agent framework is converging on. It's worth its own post, because it's quietly become the way AI apps connect to the outside world. MCP — the Model Context Protocol — is an open standard, introduced by Anthropic and now adopted across the industry, for connecting AI applications to tools and data. The tagline that stuck is 'USB-C for AI': one standard connector instead of a different adapter for every device.

The problem it solves

Before MCP, every AI app wired up every integration its own way. If you had M tools and N apps that wanted them, you were on the hook for roughly M×N bespoke integrations, none of them reusable. MCP collapses that: define a capability once behind the protocol, and every MCP-aware app can use it without custom glue. It's the same standardisation win that USB or HTTP delivered — agree on the interface, and the ecosystem does the rest.

The architecture: hosts, clients, servers

Three roles, and they're easy to mix up:

• Host — the AI application the user interacts with: Claude Desktop, an IDE, Claude Code, or your own agent.
• Client — lives inside the host and holds one dedicated connection to a server; a host runs one client per server it talks to.
• Server — a program that exposes capabilities (tools, data, prompts) over the protocol, usually wrapping some external system.

The relationship is one host, many clients, each client paired one-to-one with a server. That's how a single app can reach GitHub, your database, and your filesystem at once — three servers, three clients, one host.

What an MCP server exposes

A server offers up to three kinds of capability, and the distinction matters:

• Tools — functions the model can call to take an action: run a query, create an issue, send a message. This is the one people reach for first.
• Resources — data the app can read into context: files, records, documents. Context to ground the model, not actions to perform.
• Prompts — reusable prompt templates or workflows the server provides, so common tasks come pre-packaged.

How they connect: transports

The same protocol runs over two transports. Stdio is for local servers — the host launches the server as a subprocess and talks to it over standard input/output, ideal for something running on your own machine. Streamable HTTP is for remote servers reached over the network. Either way the messages are identical, so a server author mostly doesn't care which one a client uses.

Building one is small

The official SDKs (Python, TypeScript, and more) make a server short. Here's a complete one in Python — define a tool with a typed signature and a docstring, and the SDK turns it into an MCP tool any client can discover and call:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP('weather')

@mcp.tool()
def get_forecast(city: str) -> str:
    """Return today's forecast for a city."""
    return lookup_forecast(city)

if __name__ == '__main__':
    mcp.run()   # speaks MCP over stdio — any MCP client can now call get_forecast

Using a server is just as light: point your MCP-aware client at it (a line of config for a local server, or a URL for a remote one), and its tools show up alongside the model's other capabilities.

Why it matters

Because the interface is standard, a whole ecosystem of servers — GitHub, Slack, Postgres, the filesystem, and hundreds more — becomes plug-and-play across any client that speaks MCP. Build once, use everywhere, and switch hosts without rewriting your integrations. That reusability is exactly why agent frameworks are standardising on it rather than each inventing its own tool interface.

The security caveat you can't skip

An MCP server is code you run and hand access to your data and actions, so treat a third-party server like any other dependency: trust it, scope its credentials, and give it the least privilege it needs. Two rules carry over directly from elsewhere on this blog — resources a server returns are untrusted data, not instructions (the prompt-injection point), and every tool it exposes should be scoped and, where irreversible, gated behind approval (the tool-calling point). A standard connector is convenient; it's still a connector into your systems.

MCP didn't add a new capability — it agreed on a plug. And a standard plug is exactly what turns a pile of one-off integrations into an ecosystem.