MCP, explained: the USB-C port for AI tools (and when to build a server)

For a while, connecting agents to tools was an N×M mess: every agent needed a bespoke integration for every tool, and none of them were reusable. Model Context Protocol (MCP) is the standard that collapsed that: write a tool once, and any MCP-speaking agent can use it. The "USB-C for AI tools" tagline is glib but accurate: one connector, many devices.

What it actually is

MCP is a protocol between clients (agents like Claude Code, Cursor, and others) and servers (things that expose capabilities). A server can offer three kinds of thing:

• Tools: functions the agent can call (query a database, create a ticket, hit an API).
• Resources: data the agent can read (files, records, documents).
• Prompts: reusable prompt templates the server provides.

Servers run either locally (stdio transport, a subprocess on your machine) or remotely (HTTP transport, a hosted endpoint). The agent connects, discovers what the server offers, and uses it through the same standard interface regardless of what's behind it.

MCP's value is the network effect. Write one server and it works in every MCP client, today and the ones that ship next year. That's why it spread fast.

Why it caught on

Before MCP, if you built a clever "connect the agent to our internal API" integration, it worked with exactly one agent and broke when you switched. MCP made tool integrations portable. The result is an ecosystem: there are ready-made servers for GitHub, filesystems, databases, Slack, browser automation, and hundreds more. Plug one in and your agent gains the capability. You stop writing integrations and start composing them.

Should you build one? The honest answer

Use existing servers liberally. If a server already exists for the thing you want (GitHub, Postgres, your monitoring tool), just connect it. That's the 90% case. Near-free, too.

Build a server when you have an internal capability (a private API, an internal data source, a company-specific workflow) that you want multiple agents or developers to reuse. The reusability is the whole justification: a server pays off when it's used in many places.

Don't build one for a one-off. If only your single agent harness needs the capability, a plain custom tool in that harness is simpler: no protocol, no server to run, no extra moving part. A server only earns its keep once several agents actually share it. Reaching for a server when a function would do is the classic over-build.

The gotchas nobody mentions

An MCP server is a capability you're granting an agent, so the same disciplines from agent security apply, more so because a server can be remote and shared:

• Auth and secrets. Servers often need credentials (OAuth, API tokens). Keep them out of the agent's context: inject them at the server/proxy boundary, never in prompts, which persist in history.
• Tool-output size. A server that returns 50k tokens of raw data poisons the agent's context and torches your cache. Good servers paginate, summarize, and truncate. If you build one, bound your output.
• Least privilege. Connecting a powerful server (one that can write to prod, send messages, spend money) is granting the agent that power. Scope it, gate the destructive actions, and treat untrusted server output as a prompt-injection surface.

The lazy take

MCP is genuinely useful infrastructure: it turned tool integration from a bespoke chore into a plug-in ecosystem. Connect the servers you need, build one only when an internal capability deserves reuse across agents, and apply the same security hygiene you'd apply to any tool that can touch the world. The protocol is the boring, important plumbing that makes the agent architectures on this blog composable instead of bespoke.