A recruiter at Cosmico opens a chat and types one sentence: "start the match for deal X." They don't open the CRM. They don't export a file. They don't cross-reference two spreadsheets. Within minutes they're looking at a shortlist of talent that fits what the client is searching for.
What happens underneath is less magical than that. It's worth telling, because it's the reason I think something that gets treated as obvious today is wrong.
What Happens Underneath
When the recruiter sends that sentence, Claude uses a first MCP connector to reach the CRM and read the job description and the client's need. It uses a second one to reach our talent database. Then it applies business logic, criteria we define up front, and produces the match: a shortlist built on historical data and on what the talent has declared about themselves.
The retrieval is hybrid: keyword plus semantic. And there's an enrichment layer. We use ESCO and O*NET, the standard taxonomies of occupations and skills, European and American, to do the crosswalk between the role the client is looking for and the profiles we have. That way the match holds up even when the words don't line up.
All of this used to be human work: hours, sometimes more. Opening different systems, exporting, cross-referencing by hand. Now it's one sentence in a chat.
The Point Isn't the Speed
But the thing that interests me isn't how fast it got. It's something else.
That recruiter isn't a technical person. They didn't learn a new tool, didn't read documentation, didn't click into an interface they'd never seen. They wrote a sentence in plain Italian, inside a chat they already used every day. The adoption friction was zero. The same goes, on our side, for the people in sales, in HR, in marketing: workflows that used to take hours now happen by talking.
This is where I want to stop, because it's the thing the "MCP vs CLI" debate is, to my mind, measuring wrong.
The Opposite Position
There's a position, authoritative and well argued, that says
MCP is the wrong road. It's carried, among others, by Peter
Steinberger, a well-known voice in agentic coding. His reasoning: models were
born to manipulate text, and a CLI is text; a
sed | awk pipe does in one shot things that with MCP
you have to chain by hand, pulling down every tool's data and
then filtering. For him, documented CLIs beat MCP servers.
I'm not citing him to contradict him. I'm citing him because, rereading his argument after twelve months spent building MCP connectors in production, I noticed something simple: he and I aren't optimizing for the same goal.
Two Axes, Not a Duel
Steinberger optimizes the agent: the machine that works on its own, as efficiently as possible. I optimize adoption: that the tool actually lands in people's hands, including the hands of people who will never write a pipe in their life.
Those are two different axes. The recruiter at Cosmico doesn't want an efficient agent. They want something that works while they work the way they've always worked. For them the explicit schema of an MCP tool (field names, types, structure) isn't a burden. It's the reason they don't need to know anything about that tool.
The Same Picture, Tidied Up
An article on the IBM blog puts this in order better than I could. MCP and CLI don't solve the same problem. MCP removes uncertainty: it's deterministic, schema-driven. The CLI manages uncertainty, iterating on feedback. And they hold up in different domains. MCP shines where correctness matters more than flexibility: business systems, processes, regulated environments. The CLI wins where exploration is needed: coding, DevOps.
I look at my own case (CRM, talent database, business logic, non-technical people inside a chat) and it falls exactly into the MCP quadrant. Steinberger builds coding agents and personal automation: the CLI quadrant. We both chose well, each for the domain in front of us.
What I Think Now
So when I read "MCP is dead," what I see isn't a conclusion. It's a generalization. Someone takes a choice that's right for their own quadrant, the coding one, and passes it off as truth everywhere.
My bet, after a year spent building them, is the opposite: MCP will become standard infrastructure. Not because it "wins" over the CLI, but because for an enormous class of problems, the ones where normal people need to use complex tools without becoming technical, it's simply the right thing.
This isn't a verdict. It's what I think now, and I wrote it down to understand it better. If you build agents and you see it differently, especially if you live in the CLI quadrant, write to me.
One thread I keep pulling: the MCP quadrant is the one where correctness matters more than flexibility, and right now almost nobody measures it. That's the gap I'm building Tessera to close: an open, MCP-native benchmark for whether agents reason reliably over messy enterprise knowledge. Accuracy, provenance, and knowing when to refuse.
*Twelve months of building MCP connectors in production. Still think the debate is asking the wrong question.*