When (and When Not) to Use MCP

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

Episode 35: When (and When Not) to Use MCP

"So we put MCP on everything?" asked the new hire. Arjun smiled. "That's the question that separates a checklist-follower from an architect."

The Extra Hop

MCP is elegant, but it isn't free. Every tool call now travels through a middle layer — the agent's MCP client to the MCP server and back — before it ever reaches the tool. That's an extra hop, and an extra hop means extra latency.

Feel it:

For most applications, that added round-trip is a fine trade for one-plug scaling and central control. But there's one place it genuinely hurts: voice agents. When Nova is holding a spoken conversation, every millisecond shows up as an awkward pause. In real-time settings like that, teams often bypass MCP and wire directly to the API to keep the conversation snappy. The architecture has to fit the latency budget.

When a Direct Wire Still Wins

Latency is one reason to skip MCP. Scale is the other — in reverse.

MCP earns its keep when you have many tools and agents. If your system is small — say 4–5 agents and a handful of tools that rarely change — the MCP layer is mostly overhead: another service to host, keep running, and maintain. In that world a direct connection is often more efficient, and it keeps the debugging advantage from Episode 32: a short, explicit path you can trace end to end.

📌 The rule of thumb: MCP pays off as complexity grows. Few tools, stable, latency-sensitive → direct is fine. Many tools, many agents, changing often → MCP's central control wins. It's a design decision, not a default.

There's also a hosting cost. Running MCP means running (and babysitting) a server that must stay up. For a small team, that operational burden can outweigh the benefit.

MCP vs. Just an API (OpenAPI)

A fair objection: "We already document our internal APIs with OpenAPI — isn't MCP a redundant extra layer?"

Not quite. OpenAPI describes an API for developers to read. MCP is built to bridge the gap between a generic API definition and the specific needs of agentic tool-calling — standardised discovery (list_tools), a uniform call shape (call_tool), and metadata written for a model to choose from. OpenAPI tells a human how to call an endpoint; MCP lets an agent discover and reason about what's available at runtime. Related, but not the same job.

Who Hosts the Server? Two Org Models

In practice, MCP servers get deployed one of two ways, and which one you're in changes whether MCP is even your choice to make:

Self-managed — the team that owns the tools also builds the agents. You decide whether the MCP layer is worth it; if your toolset is small, you might skip it and bind directly.
API-as-a-service — a separate, specialised team owns the APIs and exposes them only through a hosted MCP server. Here you often have no choice: they won't support raw API access for agents, so you consume their MCP server and get the abstraction whether you wanted it or not.

💡 A rival is emerging: UTCP (Universal Tool Calling Protocol). Instead of hosting a server in the middle, everyone points at one shared definition file of tools — removing the extra hop and its latency. The catch: centralising the map isn't the same as centralising access. Each agent must still authenticate to each underlying service itself, so unified auth is harder. MCP's first-mover lead keeps it dominant for now.

More Than Tools: A Server's Four Capabilities

We've talked about MCP servers as tool libraries, but tool-calling is only the headline. A server can expose four distinct kinds of thing:

Tools do work; Resources hand over static data or files (a policy PDF, a final.csv); Prompts are reusable templates so every agent talks to the server consistently; Sampling flips the direction — the server asks the client's model to generate something. Most servers you meet lead with Tools, but knowing the other three explains what an MCP server can really be.

MCP 2.0: Stateless and Standard Auth

MCP is young and moving fast. Its 2.0 revision (released mid-2025, still rolling out) makes two changes worth knowing:

Stateless architecture. MCP 1.x kept per-connection state; 2.0 is stateless. That's a big deal for scaling and — as you'll see next episode — for resilience: a stateless request can be rerouted to a healthy server without dragging along a "sticky session."
Standard authorization. 2.0 aligns auth with industry standards — OAuth 2.0 and OIDC — instead of ad-hoc schemes, making enterprise deployments safer and more uniform.

The everyday usage patterns stay the same; the plumbing underneath got sturdier.

What Nova Learns Next

You can now judge whether to reach for MCP. But once a real organisation says yes, a new monster appears: not too few tools, but far too many — hundreds of them, flooding the model's context. In Episode 36 we tame scale with gateways.