MCP: Machines Talking in English

I spent some time digging into what MCP, the Model Context Protocol, actually is. And the more I dug, the more I found a real irony in it.

MCP is the standard that lets an AI use tools: search Notion, read a Jira ticket, create a page. The exchanges happen in JSON, in pure machine language. But what decides which tool to call, and when, is a natural-language description. A sentence, read by a model.

In short, we had machines that already knew how to talk to each other very well (that’s the whole point of an API), in their own language, not necessarily understandable by a human, but optimized, efficient. And then we put a translator in the middle that goes through English (or French), in “natural language.” We taught a machine to speak our language, so it could talk to another machine. Both sides end up doing extra work, with the potential distortions that come with it.

It’s hard not to smile.

We Were Taught the Opposite, Though

For about twenty years, we taught humans to talk like machines. I remember classes that struck me as trivial compared to the rest of my studies, but that were essential for a good Google search: no full sentences, no articles, no “please.” Pick the right keywords. Maybe use quotation marks for an exact phrase, and a minus sign to exclude a term.

Whoever typed “What is the best way to search the Internet?” came across as a beginner. Whoever typed advanced google search operators knew what they were doing.

Today, it’s the opposite. People are encouraged to write full sentences, with context, so an AI can turn them… into keywords. Which it then sends to a search engine.

The loop has closed. It just burns a lot more energy than before.

MCP Solves Real Problems. Not All of Them.

Let’s be fair: MCP isn’t a gimmick. Before it, every AI application had to write its own integration for every service. Ten AIs for a hundred services meant a thousand integrations. With a standard, that drops to ten (clients) plus a hundred (servers).

The spec has also matured a lot. Authentication, long the weak point, is clean today: the user logs in with the service, the AI receives a scoped token, no one ever handles a password. Since July 2026, the protocol is stateless and deploys like any other web service. And a company can decide, in one place, which AI gets access to which tool.

But several problems remain wide open:

• Security: The spec says so itself: MCP cannot enforce its own security principles. A tool description can hide instructions the AI will follow. Everything rests on clients, gateways, and how careful users are.
• Determinism: MCP guarantees the shape of a request, not its substance. The model picks the tool and the values. A request can be perfectly well-formed and completely off the mark.
• Context cost: Every tool you connect sends its description to the model before the first question is even asked.

And then there’s energy. According to the International Energy Agency, data centers consumed 415 TWh in 2024, about 1.5% of the world’s electricity, and are expected to pass 945 TWh by 2030. AI is the main driver.

Google states 0.24 Wh for a median Gemini query. That’s little. But that’s a simple text query. An agent going through MCP reads tool descriptions, chains calls, rereads results, sometimes starts over. In the example Anthropic published, a poorly-tooled task burns 150,000 tokens where 2,000 would do. Roughly speaking, energy follows compute volume. Routing through a model what a plain program could do alone means paying that volume every single time.

Code Mode, or the Art of Only Asking Once

There’s an approach I think is underrated: “code mode”, pushed by Anthropic and Cloudflare. Instead of calling tools one by one and routing all the data through the model, you ask it to write a script that does the work. That’s the example cited above: 150,000 tokens down to 2,000, a 98.7% savings.

But the real value lies elsewhere, in my view. A script is deterministic code. If the task comes up again, you can review it, validate it, freeze it, and replay it. No AI. No tokens. Forever.

Why do so few people do this? Because it’s so much easier to just ask the AI again. Every single time. Like calling a consultant back to redo the same calculation, instead of asking them to just hand you the spreadsheet.

(To be fair: running AI-generated code requires an isolated, monitored environment. Anthropic acknowledges this itself. And a frozen script isn’t a one-time cost either. As I wrote in AI Won’t Kill SaaS, it’s never just building, it’s also maintaining and evolving. The day the underlying API changes, the script needs revisiting. But that maintenance cost is very likely to stay far below the cost of tokens burned on every single run.)

My rule, in one sentence: the model for the unpredictable, code for the known.

Search Doesn’t Need an Interpreter

Code mode solves the case of complex, repetitive tasks. But there’s still a large mass of much simpler use cases. The user just wants to find something.

Take search, probably the most classic MCP tool. “Find my notes on the 2027 budget.” To answer, the model reads the tool descriptions, rephrases the request into keywords (well, well), calls search, reads the results, and sometimes tries again with different words. A search bar with a few filters would have done the same thing in one request. Deterministic, instant, essentially free. And the user would have seen the results, not a summary of the results.

I haven’t found reliable statistics on actual MCP usage. What I do see is that a lot of servers mostly expose trivial actions: search, read, list. When it’s the AI searching for its own work (a coding AI digging through documentation to write code, for instance), that’s perfectly justified. When you put an AI between a human and their search bar, much less so (not to mention Google’s AI Overview…).

AI shows its real value at the next step. Cross-referencing a Notion page, a Slack thread, and a Jira ticket. Synthesizing twenty documents. Answering “what did we decide, and why?” And that step comes fast, often right after the search.

Which points to a pattern I find healthier:

1. a classic search tool, with good filters, to get the right results;
2. the AI, afterward, on that chosen scope, to synthesize.

More efficient, cheaper, and the human keeps control over what the AI actually reads.

One Question Before Wiring Up an AI

MCP is good plumbing. It removes real integration work and gives companies a single point of control. But it brings neither intelligence, nor reliability, nor restraint on its own.

Before routing a request through an AI, the question to ask is simple: does this request need to be interpreted? If yes, MCP is an excellent tool. If not, a machine talking to a machine will do it better, faster, and for a lot less. And you won’t need to teach it English.

Reaching for AI at every turn is giving in to a convenience that’s everywhere today. It’s the same reflex that makes us order on Amazon, delivered tomorrow without leaving the house, rather than going to a shop, even if that means waiting for the merchant to receive the order. It’s convenient. That doesn’t make it the right answer to every need. Sometimes, you can avoid using a sledgehammer to crack a nut.

For those who want to go further, I’ve summed it all up in a dedicated page: who does what in MCP (service, developer, user, IT), how authentication works, and the classic pitfalls with their paths to a fix: MCP, Who Does What.

Cover image: photo by Dana Ward on Unsplash