Enter MCP: One Plug for Every Tool

Part of the free Generative AI course on LogicWiz, module: Nova Joins the Network.

Episode 33: Enter MCP — One Plug for Every Tool

"What if you only had to plug in once?" Arjun stared at his hundred-wire diagram, then drew a single box in the middle. Every wire suddenly had somewhere to go.

One Plug Instead of a Hundred

Last episode ended with a mess: A × T connections, each built and maintained by hand, drifting out of sync because there was no central place to manage them.

The Model Context Protocol (MCP) is the fix, and the idea is almost embarrassingly simple: put one server in the middle. Instead of every agent wiring directly to every tool, each agent connects once to an MCP server, and the server holds the tools. Multiplication becomes addition — A × T collapses to A + T.

MCP is called a protocol because it's a shared agreement — a standard way for an agent to ask "what tools do you have?" and "please run this one" — so that any agent can talk to any MCP server without custom glue. Think of it as a universal wall socket: build one plug, reach everything.

Meet the Middle Layer

Here's the shape of it. The tangle of direct wires becomes a clean hub:

flowchart LR
  A1["🤖 Support agent"] --> M["🔌 MCP server"]
  A2["🤖 Billing agent"] --> M
  A3["🤖 Research agent"] --> M
  M --> T1["🔧 lookup_ticket"]
  M --> T2["🔧 refund_payment"]
  M --> T3["🔧 search_docs"]
  M --> T4["🔧 escalate"]

The server becomes the single point of contact for a whole library of tools. Toggle between the old way and this way and watch the wiring — and the handshake the agent uses to discover a tool:

The complexity didn't vanish — authentication, connection details, the specifics of each tool — it just moved inside the server, where it can be handled once instead of by every agent. The agent's world got simple: talk to one server, in one standard way.

Client and Server: Who's Who

MCP uses a plain client–server architecture, and two words trip people up, so let's pin them down:

MCP server — the component that hosts the tools and hands them out. Your support_tools server, a Salesforce server, a database server. It's the thing with the tools.
MCP client — the component that initiates the request, living on the agent's side. When Nova wants a tool, an MCP client is what actually reaches out to the server.

Here's the reassuring part: you almost never write the MCP client yourself. Agentic frameworks — LangChain, LangGraph, Google's ADK — create and manage the client for you. It's boilerplate: connection setup, message formatting, protocol handling. You point your agent at a server; the framework spins up the client behind the scenes. Most developers never see an explicit client in their code at all.

💡 Mental model: the server is the tool library; the client is the little librarian's-assistant your framework hands you to go fetch from it. You mostly think about servers.

Building a Tiny MCP Server

So what does it take to be a tool library? Less than you'd think. The most popular way to build an MCP server in Python is a framework called fastmcp, and it's deliberately similar to writing a normal web API: name the server, decorate your functions, run it.

Walk through a real one:

Three moves: FastMCP("name") to create the server, @mcp.tool() on each function to register it, and mcp.run() to start listening. The decorator does the clever part — it reads your function's name, docstring, and typed signature and turns them into the machine-readable spec an agent needs to discover and call the tool. You write an ordinary function; MCP handles the exposure.

📌 We're reading this code, not running it, and that's on purpose. An MCP server is its own running process with its own transport — it doesn't execute inside a browser cell. In the lab you'll build the registration idea in plain Python (a tool catalog you can list), which is exactly what @mcp.tool() does under the hood.

A production server adds one more thing the demo skips: authentication — parameters and auth methods that control which agents may call which tools. That's the security the server centralises so no individual agent has to.

Change Once, Everyone Sees It

Now the payoff for all this indirection. Because the server sits between agents and tools, it decouples them — and that flips every problem from Episode 32:

A tool's parameters change? Update it once, on the server. Every agent picks it up — no hand-propagation, no drift.
New tool to add? Register it on the server; agents can discover it without being rewired.
Security policy tightens? Change the server's auth in one place, not across the fleet.

The unit of maintenance moved from "every agent-to-tool wire" to "one server." That single shift is why organisations adopt MCP as their fleet grows — it's the central control plane Episode 32 was missing.

What Nova Learns Next

Nova now binds to one server instead of a hundred tools. But how does she find out what tools the server actually has — and call one? In Episode 34, we open up the MCP conversation itself: the handshake, list_tools, and call_tool.