MCP is eating the world

Based on the comments here, a lot of folks are assuming the primary users of mcp are the end users connecting their claude/vscode/etc to whatever saas platform they're working on. While this _is_ a huge benefit and super cool to use, imo the main benefit is for things like giving complex tool access to centralized agents. Where the mcp servers allow you to build agents that have the tools to do a sort of "custom deep research."

We have deployed this internally at work where business users are giving it a list of 20 jira tickets and asking it to summarize or classify them based on some fuzzy contextual reasoning found in the description/comments. It will happly run 50+ tool calls poking around in Jira/confluence and respond in a few seconds what would have taken them hours to do manually. The fact that it uses mcp under the hood is completely irrelevant but it makes our job as builders much much easier.

As someone who does both, I have to say that the only reason I am writing MCP stuff is that all the user-side tools seem to support it.

And the moment we, as an industry, settle on something sane, I will rip out the whole thing and adopt that, because MCP brings _nothing_ to the table that I could not do with a "proper" API using completely standard tooling.

Then again, I have run the whole gamut since the EDI and Enterprise JavaBeans era, XML-RPC, etc. - the works. Our industry loves creating new API surfaces and semantics without a) properly designing them from the start and b) aiming for a level of re-use that is neither pathological nor wasteful of developer time, so I'm used to people from "new fields of computing" ignoring established wisdom and rolling their own API "conventions".

But, again, the instant something less contrived and more integratable comes along, I will gleefully rm -rf the entire thing and move over, and many people in the enterprise field feel exactly the same - we've spent decades builting API management solutions with proper controls, and MCP bodges all of that up.

> And the moment we, as an industry, settle on something sane, I will rip out the whole thing and adopt that, because MCP brings _nothing_ to the table that I could not do with a "proper" API using completely standard tooling.

100%. I suppose I understand MCP for user-side tooling but people seem to be reinventing the wheel because they don't understand REST. making REST requests with a well defined schema from an LLM is not all that hard.

I personally wouldn't be surprised if the http calling abilities of LLMs end up killing MCP, or at least greatly reducing its use. If you train LLMs to start interacting with REST APIs as a great way to make them do more then a lot of the MCP use cases go away.

You are fundamentally misunderstanding what is happening here and how this is all works.

"HTTP calling abilities of LLMs" is not some magic, new feature that is deeply integrated into LLMs. It's just a tool call like everything else - i.e. you prompt the LLM to return a JSON object that conforms to a schema.

MCP is also doing this exact same thing. It's just a wrapper protocol that tries to take care of all the details so that we don't have to deal with a million custom protocols that all accomplish the same thing but are all incompatible.

You are fundamentally misunderstanding the point I am making. LLMs have repeatedly started with training wheels and then slowly had them taken off as they have become more and more competent. MCP is another example of training wheels that will likely eventually go away. If the direct web/API calling abilities of LLMs were to improve with better trained models and some more built in support then MCP could go away and nobody would miss it.