The Third Umpire · Lesson 9 — The Standard Socket ← Course

The standard socket — MCP.

Wiring every tool to every model by hand is a tangle. MCP is one standard socket — so any tool plugs into any app.

Last page, the umpire called on instruments. But someone has to wire each instrument into the booth — and by hand that turns into a mess. Every app gets custom-connected to every tool, and a tool built for one app won't work in another.

MCP — the Model Context Protocol — is an open standard that fixes this. A tool exposes itself through MCP once (as an MCP server); any MCP-capable app or model (an MCP client) can then plug straight in. Build the connector once, and it works everywhere.

Picture the umpire's review console. Without a standard, Hawkeye, Snicko and Hot-spot each need their own custom cabling into every booth. Give the console one standard socket, and any instrument that speaks it plugs straight in — the same instrument, working in every booth. (Anthropic's own line for it: MCP is “a USB-C port for AI”.)

The whole difference is the wiring. With A apps and T tools and no standard, you need A × T custom integrations — and adding one tool means wiring it to every app. With MCP it is A + T: each tool and each app connects to the socket once.

Flip between the tangle and the socket, and add a tool to each. Watch the custom wiring blow up — while the socket stays tidy.

Without a standard, every app is wired to every tool. Flip to MCP and add a tool.

Expose once; connect from anywhere.

A tool becomes an MCP server; any MCP client discovers and uses it — no bespoke glue per app.

# a tool exposes itself once, as an MCP server
hawkeye = MCP.server(tools=[track, predict])   # runs anywhere

# any MCP client — Claude, an IDE, your app — connects; no custom glue
client.connect("hawkeye")      # discovers its tools automatically
reply = umpire.review(appeal)  # can now call hawkeye.track(...)

Build once, plug in anywhere.

MCP is a common socket between AI apps and the tools and data they use. A tool speaks MCP once and every MCP app can use it; an app speaks MCP once and gets the whole ecosystem. It turns A × T bespoke integrations into A + T reusable ones.

And it's an open standard, not one company's cable — Claude, ChatGPT, and IDEs like VS Code and Cursor all speak it. Write a connector once; plug it in anywhere.

Next: build a server →
Go deeper — what MCP actually is optional

Servers and clients

The architecture is just two roles. A tool or data source is wrapped in an MCP server; the AI app is an MCP client; the two talk over one shared protocol. Write a server for your database once, and every client that speaks MCP can use it — that is the whole trick.

Not just tools — data and prompts too

MCP carries three kinds of thing: tools to call (actions), resources to read (your files, a database — this is where RAG's archive can live), and ready-made prompts or workflows. It is a socket for everything a model needs from the outside world, not only functions.

Open, and widely supported

MCP is open-source and vendor-neutral. A growing set of apps and servers already speak it — Claude, ChatGPT, editors like VS Code and Cursor — so a server you write is reusable far beyond any single product. That reach is the point: build once, integrate everywhere.

A socket is a door — mind who you let in

Plugging in a server grants it a foothold and grants the model its tools. Connect only servers you trust, and be deliberate about what each is allowed to do — the action-tool caution from the last page, now at the scale of a whole ecosystem.