The Video Assistant · Lesson 9 — The Standard Socket ← Course

The standard socket — MCP.

Every tool has to be plugged into the model. MCP is the standard socket that lets any tool plug into any app.

Last page, the VAR called on instruments. But someone has to wire each instrument into the booth — and doing that by hand gets ugly fast. Every app ends up custom-connected to every tool, and a tool built for one app doesn'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 VAR's review console. Without a standard, goal-line technology, offside tech and multi-angle replay each need their own custom cabling into each booth. MCP is a standard socket on the console — any instrument that speaks it just plugs in, and the same instrument works in every booth. (The official one-liner: 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 = VAR.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.