MCP: The Universal Plug
Function calling wires one tool into one app. MCP is the standard socket so any app can use any tool — build it once, plug it in everywhere.
You wired a weather tool into your chatbot with function calling (L17). Now you want that same tool in your IDE assistant and a teammate’s app — and you also want to add a database tool, a calendar tool, and a docs tool to all three. Done the bespoke way, that’s a custom integration for every app × every tool: the work explodes. There has to be a standard plug. There is — it’s called MCP.
The N×M integration problem
Function calling connects a model to a tool, but the wiring is bespoke — written specifically for that app and that tool. So with N apps and M tools, you face up to N×M custom integrations to build and maintain. Five apps and five tools is twenty-five little bridges, each able to break on its own. That multiplication is the real cost, and it’s exactly the kind of mess a shared standard exists to kill.
MCP is the universal plug
MCP (the Model Context Protocol) is an open standard for how an AI application connects to outside capabilities. Two roles: a client (the AI app / host — a chatbot, an IDE assistant, your own program) and a server (a small adapter that exposes capabilities). A server can offer three things: tools (functions the model can call), resources (data/context it can read), and prompts (reusable templates). Build your weather tool once as an MCP server, and any MCP-compatible client can discover and use it — no per-app glue.
Before MCP: weather tool hand-wired into the chatbot. Want it in the IDE assistant too? Re-implement. Add a DB tool to both? Two more integrations. → N×M. With MCP: wrap the weather tool as one MCP server. The chatbot and IDE assistant are both MCP clients — they connect and discover it automatically. Add a DB MCP server and both clients gain it with zero new glue. → N+M.
What changes — and what doesn’t
The model’s job is unchanged: it still emits structured tool-call requests exactly like L17. What MCP standardizes is the plumbing around that — how a client discovers which tools a server offers, the format of the call, and the transport carrying it. You stop hand-writing integration code and start speaking a common protocol. Honest caveat: MCP is plumbing, not magic. You still have to secure your servers, validate inputs, and handle the same agent failure modes — the next lessons are about exactly that. MCP just means you wire it once.
Think of USB-C (or a standard wall socket). Before standard plugs, every device needed a custom adapter for every outlet — an N×M nightmare of dongles. A standard plug means any device works in any socket: each device implements the plug once, each socket implements it once, and everything interoperates. MCP is that standard plug between AI apps and the tools/data they use — build the plug once, and it fits everywhere.
A team’s integration math, before and after: 1. They have 4 AI apps (chatbot, IDE helper, support tool, internal dashboard). 2. They want 3 shared capabilities (weather, database, calendar). 3. Bespoke way: 4 × 3 = 12 custom integrations to write and maintain. 4. MCP way: 3 capabilities become 3 MCP servers; 4 apps become 4 MCP clients → 4 + 3 = 7 implementations. 5. Now add a 5th app: it instantly works with all 3 servers — one new client, zero new tool integrations. Same tools, same models — but the integration cost went from multiplicative to additive.
This is the reading. The interactive version — active-recall quiz, a hands-on experiment you run in your own AI, and an earned mastery check — is free in the app.
Start this lesson free →