What MCP Is Actually For, and When You Don't Need It

By Pooja Goenka · 2026-09-30

Three agents. Four tools. That is twelve integrations, each with its own authentication, its own error shapes and its own reason to break on a Tuesday. Add a fifth tool and you are writing three more. Add a fourth agent and you are writing four more.

Nobody plans that architecture. You arrive at it. The support agent needs the ticket system, so you wire it up. Then billing needs the same ticket system, and it is easier to write a second client than to extract the first one. Eighteen months later there is a mesh, and the person who understands any given strand of it has left.

The Model Context Protocol is the answer to that specific problem. It gets explained as "USB-C for AI", which is not wrong and does not tell you much. USB-C tells you the shape of the plug. It does not tell you what you give up, what the model actually sees, or when the whole idea is a mistake. I want to go through those three.

The arithmetic, which is the entire argument

Wire agents directly to tools and the connections you maintain are agents multiplied by tools. Three agents and four tools is twelve. Six agents and eight tools is forty eight. The growth is what hurts: every new agent costs you one integration per existing tool, and every new tool costs you one per existing agent.

Put a protocol in the middle and the count becomes agents plus tools. Three and four is seven. Six and eight is fourteen. Each agent learns one way of talking to tools. Each tool gets exposed once, to whoever asks.

The work does not vanish. Somebody still writes the server that wraps the ticket system, and somebody still owns its credentials. What changes is that the work stops multiplying. That is a smaller claim than the marketing makes and a much more useful one, because it tells you exactly when the trade is worth taking.

What actually goes over the wire

The protocol is smaller than people expect. Four phases, and most of it is two request and response pairs.

Connect. The client opens a connection and presents credentials. The server checks them and grants access, or does not. Nothing before this point is trusted, which is worth saying out loud because a lot of tool wiring in the wild has no equivalent step at all.

Discover. The client sends list_tools(), which means "what do you have". The server answers with a catalog. For each tool: a name, a description of what it does, and a signature with the arguments and their types. lookup_ticket, refund_payment, search_docs, each with that metadata attached.

The client did not know the toolset in advance. That is the part that makes this a protocol rather than a convention. You can add a tool to the server and every agent that connects tomorrow can use it, without anyone shipping a new agent.

Call. The model reads the catalog and decides. A user asked about ticket T-1003, so it picks lookup_ticket. Deciding is the whole of its job here; it does not execute anything. The client then sends call_tool("lookup_ticket", { "ticket_id": "T-1003" }), the server runs the real thing, and the result comes back: "escalated to engineering".

Answer. The model turns that raw string into a sentence for the person who asked.

That is the loop. Discovery, intent, execution, result. If you have written a plain tool calling loop before, it is the same shape, with the tool list arriving over the wire instead of being hardcoded in your prompt.

The description field is the interface

The model chooses a tool from its name, its description and its signature. That is all it gets. It cannot read your source, it has no memory of your architecture decisions, and it will not ask a colleague. So the description is doing the work an interface does, and should be written with that in mind rather than as a note beside it.

Write search_docs with the description "searches documents" and you have built something that will be picked for the wrong requests and skipped for the right ones, and the failure will look like the model being stupid. Write "full text search over the internal support knowledge base, returns up to five matching articles, does not cover billing policy" and the same model starts behaving. Nothing changed except the sentence you wrote for it.

Teams put real effort into their OpenAPI specs because another engineer will read them. The MCP description has a reader too, and it is less forgiving than the engineer, because it will make a decision from an ambiguous sentence rather than asking what you meant.

When MCP is the wrong choice

I am not going to pretend the trade is free. Routing a tool call through a client and a server adds a round trip, and a round trip has a cost.

Say the tool itself takes 150 milliseconds. Through MCP the same call is nearer 230, with the extra 80 spent on the hop. Whether that number matters is entirely a question of what you are building.

A back office job with a thirty second budget will not notice. A chat assistant working to roughly a second will not notice either. A voice agent, where the budget is something like 200 milliseconds before the conversation starts to feel broken, has a real problem: the direct call fits and the routed one does not. Same protocol, same tool, opposite answer, and the only thing that decided it was the latency budget.

There is a second case, and it is more common than the first. One agent and two tools is two integrations wired directly, and three if you put a protocol in the middle. At that size MCP is more machinery, not less. The arithmetic that makes it worth doing only starts to bite once the mesh has some size to it, and reaching for it on day one is how you end up maintaining a hub that serves one client.

Where A2A comes in

MCP connects an agent to tools. Agent to Agent, or A2A, is the level above: agents discovering what other agents can do and handing work to each other. An agent looks up another agent's capability card, sees what it accepts, sends it a task, and gets a result back.

They solve adjacent problems and people conflate them constantly. The useful question when you are designing is whether the thing on the other end is a capability or a colleague. A ticket lookup is a capability. A legal review that has its own judgement and its own tools is closer to a colleague. Choosing wrongly is not fatal, but it produces architectures that feel strange to work in for reasons nobody can name.

Why it is worth learning now rather than waiting

Protocols usually deserve suspicion. Most of them are one vendor's convenience dressed as a standard, and the honest move is to wait and see whether anyone else shows up.

MCP has already had that test. Anthropic published it in late November 2024 and open sourced it. OpenAI adopted it across its Agents SDK in March 2025, Google DeepMind confirmed support for Gemini in April 2025, and in December 2025 Anthropic handed governance to the Agentic AI Foundation under the Linux Foundation, which makes it vendor neutral in the way that actually counts. There are now more than sixteen thousand MCP servers in the wild.

That is a different situation from a protocol with one backer, and it is the reason I would learn this one properly instead of waiting to see if it survives.

Where you can step through it

Chapter nine of the LogicWiz Generative AI course is built on exactly this. One visual wires the same set of agents and tools both ways and lets you add agents and APIs while the connection count updates, so you watch twelve become forty eight on one side and seven become fourteen on the other. Another plays the handshake out as a message thread, with the model's reasoning shown between the messages, so you can see what it had to decide from. A third puts the extra hop against three latency budgets and lets you pick which product you are building.

The chapter then goes up a level into A2A, capability discovery and delegation, and finishes on choosing between the two protocols for a given job.

Everything is free. Chapters one to three open with no account at all, and a free account carries you from chapter four onward. No card at any point.

If you only take one thing from this: before you adopt MCP, count your agents and your tools and multiply. If that number is small, you do not have the problem it solves yet.