Before MCP, every time you wanted your AI to use a tool — a database, GitHub, your file system — you wrote custom glue code for that specific model talking to that specific tool. Ten tools and three models? That’s potentially thirty integrations to build and maintain.
MCP (the Model Context Protocol) fixes this with one idea: a shared standard.
The USB-C analogy
Think of MCP as USB-C for AI. The port is the same everywhere. Any compliant device plugs into any compliant host. You don’t build a new cable for every laptop.
- The host (your AI app or agent) speaks MCP.
- The server (a tool or data source) speaks MCP.
- They connect, and the host discovers what the server can do — automatically.
What an MCP server offers
A server exposes three kinds of things over the protocol:
- Tools — actions the model can call (
create_issue,run_query,send_email) - Resources — data the model can read (files, rows, documents)
- Prompts — reusable templates the server suggests for common tasks
The host asks the server “what have you got?” and the server answers. No hard-coding.
Host (agent) ──"list your tools"──► MCP Server (e.g. GitHub)
Host ◄──"create_issue, list_prs, ..."── Server
Host ──"call create_issue(...)"──► Server
Host ◄──"done, issue #42"── ServerWhy this is a big deal
Write a tool once as an MCP server, and every MCP-capable agent can use it. Build an agent once, and it can use every MCP server. The integrations stop being N×M.
Practically, that means:
- Reuse — the same Postgres or Slack server works across all your agents.
- Composability — snap together servers like LEGO for a given task.
- A growing ecosystem — pull in community servers instead of writing your own.
When you’d reach for it
If you’re building an agent that needs to touch real systems — your code, your data, third-party APIs — MCP is how you give it hands without bespoke wiring each time.
Next up in this thread: writing your first tiny MCP server. Subscribe via RSS so you don’t miss it.