MCP is a fad - except when it isn't

Is the Model Context Protocol a fad? For one developer wiring one agent to one tool, basically yes. For a company wiring a hundred agents to fifty systems, not even close. Both things are true at once, and the fight only gets loud because people keep forgetting to say which case they’re arguing about.

The strongest version of the skeptic’s case deserves a fair hearing before you wave it off. A widely-shared essay titled “MCP is a fad” argued that the protocol “is, more or less, handling serializing function call schemas and responses,” which is a polished way of saying it does something small. The discussion that followed piled on, and one line stuck: “My agent writes its own glue code so the benefit does not seem to really exist in practice.” Hand a capable model a sandbox with a filesystem and a shell, the reasoning goes, and it’ll cobble together whatever connector you need on the spot. No protocol needed.

For the person making that argument, it’s correct. It also walks right past where the value actually lives, which is part of the bigger question of where AI fits into real operations: the answer usually turns on scale and accountability, not raw model smarts.

Steelman the critics before you defend MCP

Take the critique at full strength, because a weak version of it is easy to knock down and useless to argue with. The essay’s core claim is that MCP solves a trivial problem. A coding agent is brilliant at writing small utility scripts, so a technical user “will be hard-pressed to find a tool an agent could not one-shot in the programming language they are most comfortable in.” If you’re a developer with a terminal, that’s just true. You don’t browse a registry to call an API you understand. You ask the model to write three lines, you read them, you run them. Adding a protocol, a server process, and a discovery handshake on top of that feels like ceremony around something that already worked.

Push the steelman one notch further, because the essay does. If a service already ships an OpenAPI spec, a model can read it and call the endpoints directly, with no server sitting in between. The protocol, in that light, wraps a thing that already described itself. And the CLI point is sharper: a tool the agent runs through the shell costs nothing to keep in context, executes in a sandbox you control, and leaves a command history you can read line by line. Against a single, well-understood service, those are genuine wins, and an honest scorekeeper hands the round to the skeptics.

The context-window argument lands too. Every tool an MCP server advertises eats tokens in the model’s working memory, whether the agent uses it or not. Connect a handful of chatty servers and you’ve spent a real slice of the context budget describing tools before the model has done a single useful thing. Critics who say “a CLI does this better” aren’t wrong about their own setup, because a CLI the agent already knows costs nothing to describe.

So far the skeptics are winning on points.

The honest reply isn’t to deny any of this. It’s to ask what changes when you stop picturing one person at a laptop and start picturing an organization.

Where the fad argument quietly breaks

The argument breaks the instant the work stops being one agent and one tool. Picture twelve different AI applications across your company that each need to reach the same eight internal systems. Built the old way, that’s a matrix of point-to-point integrations, and every one of them is a thing somebody has to write, test, and maintain when an API shifts under it. AWS spelled out the math in its own MCP guide: the old approach makes you “build and maintain” a full grid of custom integrations, and a shared protocol collapses that into “M+N implementations.” Build one server per system, and every compliant client reaches it without bespoke wiring.

That’s not a hobbyist’s problem.

It’s an operations problem.

Make it concrete. Say you run a support assistant, a sales-ops agent, an HR onboarding bot, and a finance reconciliation tool: four AI applications. Each one needs to reach your CRM, your ticketing system, your HRIS, your data warehouse, and your chat platform: five systems. Point-to-point, that’s twenty integrations, each with its own auth, its own error handling, and its own breakage the morning one of those five vendors ships an API change. Add a fifth agent next quarter and you’re not adding five connections; you’re adding them to a grid that was already groaning. The one-script-per-link trick that felt elegant for the first agent becomes a maintenance tax that compounds, and nobody on the team volunteered to babysit twenty hand-built bridges.

Who owns that grid when it cracks?

The skeptic’s sandbox-and-shell trick assumes one model, one task, one developer who can read the generated code before it runs. None of those assumptions survive contact with a real company. You don’t have one model; you have whichever ones each team picked. You don’t have one task; you have hundreds, running unattended. And you very rarely have a human reading the glue code each time, because the entire point was to not write integrations by hand. Turns out the protocol earns its keep exactly where the critique stops looking: the messy middle where many callers, many systems, and many people who never see the code all have to coexist.

What changes when it’s a hundred agents, not one

Scale doesn’t just multiply the work. It introduces problems a single script never had to think about, and they’re the boring ones that decide whether a system survives an audit.

The biggest lesson we’ve learned building Tallyfy’s own MCP server is that the protocol is the easy part and the governance around it is the hard, unglamorous bulk of the work. A one-off script answers to its author. A standard interface, hit by a hundred agents on behalf of real users, has to answer four questions the script never faced. Who is each agent acting as? What is it allowed to touch? What did it actually do, in a log a compliance officer can read? And can you swap the underlying model next quarter without rewriting every integration you own?

Walk those four questions out to their consequences and the distance from a script gets obvious. Who an agent acts as matters because the first thing an incident review needs is the identity behind an action, and a script running as a shared service account can’t tell you which user or team it was really serving. What it’s allowed to touch matters because “everything the script’s credentials had” is precisely how a small mistake turns into a large one. What it actually did matters because an auditor will ask for a per-action record, and “we logged that it ran” is not the same as “here is every call it made and what changed.” None of these are exotic worries. They’re the same questions every operations leader already answers for human access, and the day agents act at scale, the questions show up again with the same teeth.

That last one is the quiet killer of the do-it-yourself approach. Vibe-coded glue is welded to whatever model wrote it and whatever shape that model assumed. Switch from one provider to another, or add an open-source model for cost reasons, and a pile of hand-built connectors becomes a pile of rewrites. A shared protocol is the seam that lets you change the brain without re-plumbing the hands. AWS makes the same case from the governance side, noting that a standard lets you “enforce consistent security and governance policies” across all of it instead of per-script. For a solo project, none of that matters. For a regulated company, it’s the difference between a tool you can defend and one you can’t.

Picture the swap concretely. A team builds its integrations against one vendor’s model, then moves to a different provider six months later because the pricing changed. The protocol-backed clients keep working, because the contract was with the standard, not with the model. The hand-rolled scripts, quietly tuned to the old model’s quirks, turn into a sprint of rewrites nobody put on the roadmap. That migration cost is invisible right up until the day you decide to switch, which is exactly the kind of bill the fad argument never adds up.

MCP and vibe coding aren’t fighting

Here’s the part both camps get wrong: MCP and the “just generate the code” crowd aren’t actually competing. They solve different layers, and the smart move is to use each where it fits. We’ve argued before that vibe coding is gutting the connector marketplace, and that’s still true. Describing an integration in plain English and getting working code beats dragging boxes around a visual builder for most one-off connections. The thing is, that argument is about replacing brittle middleware, not about replacing a standard for how agents and tools talk.

Use vibe coding to build the connector. Use a protocol to expose it consistently, with access control and a record of every call.

One writes the integration; the other governs how a fleet of agents reaches it. A vibe-coded script with no standard around it is fine until it’s the fortieth one and nobody remembers which model assumed what. A protocol with no easy way to build connectors is friction nobody wants. Put them together and you get fast construction underneath a stable, governed surface, which is roughly the architecture we keep landing on.

Picture the split in a real shop. An operations manager describes a connection they need, and a coding model writes it, fast, with no ticket filed and no marketplace to browse. That’s the vibe-coding win, and it’s real. Then that connection gets registered behind a protocol so the dozen agents that rely on it all reach it the same way, with the same access checks and the same log, instead of each one hauling around its own private copy. Construction stays cheap. Governance stays consistent. You never had to pick a side, because the two halves were solving different problems all along.

The fad framing treats this as either/or. Real systems treat it as both, and that’s why the protocol kept maturing into an industry standard instead of fading the way the skeptics predicted.

So, fad or foundation?

Run the title question back one more time, because the answer is genuinely “it depends,” and the dependency is the useful part. If you’re one developer with a shell and a problem you understand, MCP is overhead you can skip, and anyone insisting otherwise probably has a product to move. If you’re an operations leader with a dozen AI tools, real systems behind them, and an auditor who’s going to ask what touched what, the protocol is the cheap part of staying sane.

The mistake is arguing the question in the abstract, as if there’s one answer for everyone. There isn’t.

Notice how often the fad debate is really two people describing different companies. One has a single repo, a sharp model, and full control of the code that runs; for them the protocol is friction and they should skip it. The other has forty teams, a dozen models, and an auditor who shows up every spring; for them it’s the cheapest insurance on the shelf. They talk past each other because each one assumes their own situation is the universal one. The useful question was never “is MCP good.” It’s “good for which of these two companies,” and the honest answer flips completely depending on which chair you’re sitting in.

What actually decides it is whether you need accountability at scale or just a quick connection that works once. A hundred agents reaching your systems with no shared standard, no per-call record, and a different hand-built bridge for each one isn’t lean engineering. It’s a kludge waiting to become an incident, and the cleanup costs more than the protocol ever would have.

The skeptics aren’t wrong about their laptop. They’re answering a smaller question than the one a company has to ask, which is not “can a model write glue code” but “who’s accountable when a hundred of them do it at once.” That’s the question worth building around, and it’s the same reason it’s safer to fence an agent inside a defined process than to hand it a master key and hope. Fad for one. Foundation for many. Both true, depending on which one you are.