←back to thread

MCP is eating the world

(www.stainless.com)
335 points emschwartz | 2 comments | 21 Jun 25 16:30 UTC | HN request time: 0.453s | source
Show context
faxmeyourcode ◴[24 Jun 25 16:58 UTC] No.44368295[source]▶
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.

replies(7): >>44368648 #>>44368903 #>>44368929 #>>44368954 #>>44369304 #>>44374580 #>>44375982 #
rcarmo ◴[24 Jun 25 18:36 UTC] No.44369304[source]▶
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.

replies(4): >>44371922 #>>44375100 #>>44375484 #>>44376382 #
1. cdblades ◴[25 Jun 25 12:13 UTC] No.44376382[source]▶
> because MCP brings _nothing_ to the table that I could not do with a "proper" API using completely standard tooling.

This is what drives me crazy and has stopped my tinkering with MCP in its tracks: what is the point? It's not bringing anything new. It's usually not easier to set-up than what you're describing. Or, if you absolutely must have an LLM in the mix, normal function calling does just as well as MCP.

It's a real, "I feel like I'm taking crazy pills" moment: there's all this hype and bluster and "wow look at this", but there is no "this". Everyone's talking about "it can do" and "it'll be amazing when", but there's nothing actually built and present and ready that is impressive.

replies(1): >>44382188 #
2. zingababba ◴[25 Jun 25 21:59 UTC] No.44382188[source]▶
It's not really MCP that is 'this', MCP is just the glue that makes the NLP as frontend easy to conceptualize in terms of application. Everyone is getting excited because it's now relatively obvious how you can go from talking to LLM -> large orchestration happening, even though you could do this already with langchain or whatever.

MCP is basically just a protocol you can bring into the context window, do your LLM coding magic, then start up your MCP server and test your tool chain for your NLP as frontend stuff. The only difference is now it's not deterministic so stuff will get randomly fucked up.