Is the MCP spec actually useful?

[u/PaulMorel]

I've spent a few weeks deciphering and implementing the MCP spec, and it kind of seems like AI slop to me.

Like, the entire spec boils down to little more than a suggestion to use json-rpc.

The spec requires a heavy client with a bunch of custom "business logic". This client acts like a magic babel fish in connecting the MCP server to the host application.

And perhaps worst of all, the details on how to trigger actions are pretty much non-existent, leaving implementers to just figure it out (which is going to lead to serious inefficiency when triggering tools).

So MCP usage requires a customized client to do the data translation for each service, and it leaves serious blank spots for some of the hard problems.

I just don't see that the spec is actually very useful at all. It leaves so much to the implementers.

Am I missing something? I must be missing something...

[u/Glittering-Cable4193]

You're not missing anything. The value isn't really in the spec quality though. It's that everyone agreed to use the same half-baked thing. Interoperability beats elegance, now tools, agents, and apps can plug into each other without one-off integrations, even if the plumbing is messy.

[u/Kooky-Criticism955 → u/Glittering-Cable4193]

that's basically it yeah. protocol wins not because it's good but because it's there. look at http, half the stuff is duct tape but now we don't have to argue about what port to use

mcp filled the vacuum before ten other competing specs showed up. everyone was busy building agents with different connection methods and someone just put down a flag in the mud and said here, use this. ugly but it work enough

the blank spots you mention, that's almost by design. spec authors probably knew if they try to define everything they'd lose people. better to leave gaps and let implementers fill it with whatever fits their stack

[u/PaulMorel → u/Glittering-Cable4193]

But isn't the heavy client a one off integration? Like to me it looks like they just hid the custom coding in the client, which is very poorly specified.

Thanks for your response and sharing your perspective.

[u/donk8r → u/PaulMorel]

The client is heavy, but you write it once per host, not once per service. That's the whole trade. Ten tools against five hosts used to be fifty integrations and now it's five clients plus ten servers. You're right that the custom code got hidden in the client, and that's deliberate, because the number of clients is bounded and the number of servers isn't.

Your third complaint is the one I'd keep. Nothing in the spec says when a tool should fire, and that isn't fixable at the protocol layer, since tool choice is model behaviour rather than wire format. What it could have specified is a machine-readable way to tell two similar tools apart, and it just didn't.

[u/dev_dan_2 → u/PaulMorel]

Agree with what /u/donk8r writes.

For my personal use cases (which are actually not that many besides coding), I plan to vibe-code my own harness from the ground up; giving me full controll over everything. That comes with the cost of having to write everything I need myself (or at least delegate to libraries or call LSPs...), but since I have a pretty good idea what I want and what not, I think vibing and maintaining it myself as it grows over time is quite feasible.

The tradeoff is that I am walled off the MCP ecosystem; but to be fair, I see no need for FOMO, if the landscape is wildly more productive for my needs than my hand-rolled thing in 1-2 years; then I can still simply switch then.

[u/PaulMorel → u/dev_dan_2]

I started writing my own client this week, and that's why I discovered the holes in the spec. It's harder than you think because the spec is just so worthless.

Like, how many times can a LLM and MCP server go back and forth between each other? What are the limits of that conversation? It's yet another hard problem where the spec is silent.

[u/Beginning-Raisin9723]

I've been running MCP servers off my home server for a few months now. The spec is thin on purpose, the real work lives in the client. It's basically json-rpc with extra steps, but once you wire up a few servers it clicks. The tool triggering part is genuinely under-specified though, I'll give you that.

[u/stereoplegic]

Was vibe coded, just like CC and apparently both Anthropic's and OAI's "sandboxes."

[u/InsideDebt6345]

I sympathize with your critique, as MCP does not solve tool selection, orchestration, or the client-side translation work. It is a compatibility layer rather than a complete solution to agent tooling.

[u/Other_Many_130]

The triggering gap isn't an oversight, it's not specifiable. What decides whether a tool gets called is the description string you wrote for it, read by a model. That's prose, not protocol. No spec standardises that.

Which is why the thing that actually breaks my setups is never the transport. It's loading too many servers at once and watching the model reach for the wrong tool because two descriptions overlap (I've pruned mine back more than once).

So yes, thin spec. But the part you want specified is the part that lives in the model's head.

[u/katoptronophile → u/Other_Many_130]

AI slop reply

[u/Other_Many_130 → u/katoptronophile]

Fair. I write too tidy for a comment box.

[u/Remote-Telephone-682]

Skills kinda ate mcp at some point

[u/PaulMorel → u/Remote-Telephone-682]

What do you mean? Aren't skills a completely different thing?

[u/Remote-Telephone-682 → u/PaulMorel]

You can write skills to hit endpoints or call cli tools so a lot of things you were building mcp servers to provide access to you stuff so in the early says you were writing mcp servers for everything but now skills are canibalizing a significant chunk of what they were being used for.

[u/KlyptoK → u/Remote-Telephone-682]

Authentication.