If they said what it really was (see my other comment in this thread [1]), they couldn't leverage it to make more money/get more investors.
> basically RAG with a bit of sugar on top
Is not correct. MCP can work very well with a RAG system, providing a standard way to add context to a model call, but itself doesn't do any Retrieval.
Over the years there have been a huge variety of ways information such as tool use, RAG context, and other prompting information has been communicated to the model (very often using some ad hoc approach). MCP seeks to clarify and standardize how that information is communicated to an from the model. This, as the poster points out, allows you to reuse tools, RAG, etc with any supporting model rather than hacking these together to work with each on individually.
Previously you would have had to come up with your own way to add the retrieved metadata from RAG to the model, use the vendor specific method of tool calling and then write you own method of tool dispatch once a tool call has been returned.
That's misrepresentation of what I said. I didn't say that MCP replaces RAG, just that it's essentially a RAG system with some syntax sugar on top (which your response confirms).
It's great that it adds some standardization to the process of implementing RAG, but under the hood that's the engine of MCP.
I saw a tweet stream that said something like "if you think MCP is the same as REST, you're not thinking big enough" followed by a bunch of marketing speak that gave off LinkedIn web3 influencer vibes. I saw a blog post that says MCP is better because it bridges multiple protocols. Okay, and?
I really want to get this, but I don't know how to square "LLMs are hyper intelligent" with "LLMs can't figure out OpenAPI documentation."
MCPs don't solve this entirely either, that's why GitHub's MCP has ability to offload modules to not confuse LLM with all the options.
Hopefully soon this stuff will get ironed out because yeah, auth is super important.
It's not like you can't do this manually (or automatically) but MCP makes things like this so much easier:
> Check JIRA against my org-mode and identify any tasks that I worked on that haven't been reflected in either system.
Undoubtedly there's an incredible amount of hype, but there's a reason for it. I prefer MCP tools that are read only for now.
gptel can use MCP server tools in Emacs by integrating with the mcp.el package, here's a demo: https://i.imgur.com/WTuhPuk.mp4.
mcp.el: https://github.com/lizqwerscott/mcp.el
Relevant gptel README section (you'll have to unfold the details block): https://github.com/karthink/gptel?tab=readme-ov-file#model-c...
> any sane engineer won't just let an LLM loose, they'll build guardrails around it
Sure seem to be plenty of insane engineers around these days. And, worse - plenty of them with good marketing teams that can convinced non-engineers that their systems are "safe" and "reliable".
<small>hmm, generative ai blockchain?...</small>
Edit: that was 11 years ago?!? Wow.
MCP is a standardized set of API endpoints that makes it easier for LLM's to discover and operate with all the other regular APIs you have.
Each MCP server still needs to handle auth differently depending on what it's connecting to. A GitHub MCP server needs GitHub tokens, a database server needs database credentials, an email server needs SMTP auth, etc. The client application now has to manage and securely store N different credential types instead of implementing N different integrations.
So yes, the protocol complexity is reduced, but the real operational headache (managing secrets, handling token refresh, dealing with different auth flows) just gets moved around rather than solved. In some ways this might actually be worse since you now have N different processes that each need their own credential management instead of one application handling it all.
This doesn't make MCP useless, but the "M x N to M + N" framing undersells how much complexity remains in the parts that actually matter for production deployments.
I think this problem is inherent to connecting to a bunch of different providers. Unless all the providers were the same company or had to register directly with a single company and then proxy through but even then now you’ve just moved the problem.
Setting aside expected criticism about this being some middleware layer, but we’ve launched a solution to this problem:
An MCP “SSO”, where you install and auth your MCP servers into profiles (collections of servers), which we virtualize into a single MCP server with only a single OAuth flow — simplifying the experience substantially for both the user of the MCP servers and the clients connecting to them.
Still, funny to see numerous hyped GenAI start-ups with bad monetary traction jump on the bandwagon and proclaim MCP as the latest revolution (after RAG, Agents, you name it)...All of these are simply tools which add zero value by themselves. Looking forward to the VC wake up calls.
The MCP or something similar should exist but it should be handled %100 by AI so the people can do the stuff that is important and human related.
It rubs me the wrong way seeing people trying to understand this and if you take it on face value it appears that now AI can do the code but MCP is so hard that it needs a human who studied that so they can talk.
Is this piece of JSON really the last frontier of programming?
So far, the entire AI story feels very much like the opposite. The AI is (possibly) taking over the creative/fun stuff, leaving human beings to do the annoying parts.
Many of MCPs shouldn't have existed, IMO. Here is an example: I wanted amazon q to interact with github, so I added to its context that it can use `gh-cli` and it it worked pretty well. Sure, it hallucinated things about json schema every new session, but it figured out how to "wait for checks to pass and merge if it's green."
To make its and mine life easier, common things were saved as scripts in bin/ and Justfile (also generated by it).
I needed it to fetch stuff, so i told it to use `curl`.
Using github's official MCP bricks chat session every time for me.
It's basically RAG with a bit of sugar on top. What spooks me is how few people hyping MCP seem to understand that.
I genuinely believe that there will be (and potentially already are) use-cases when it comes to AI agents, but we really to step back and re-think the whole thing. In the middle of writing a blog post about this, but I really do think genAI is a dead-end and that no one really wants to chill out for a second and solve the hard stuff:
- Needle in a haystack accuracy
- Function calling (and currying/chaining) reliability
- Non-chat UI paradigm (the chat-box UI is a dead-end)
- Context culling (ignoring non-relevant elements)
- Data retrieval given huge contexts (RAG is just not good enough)
- Robotics
- Semantic inference
nythroaway048•6mo ago
hnlmorg•6mo ago
It’s great to have a standard way to integrate tools but I can’t say I have much love for MCP specifically.
s900mhz•6mo ago
I think it all comes down to discovery. MCP has a lot of natural language written in each of its “calls” allowing the LLM to understand context.
MCP is also not stateless, but to keep it short. I believe it’s just a way to make these tools more discoverable for the LLM. MCP doesn’t do much that you can’t with other options. Just makes it easier on the LLM.
That’s my take as someone who wrote a few.
Edit: I like to think of them as RCP for LLM
pcwelder•6mo ago
For example in [1], whole `responses` schema can be eliminated. The error texts can instead be surfaced when they appear. You also don't need duplicate json/xml/url-encoded input formats.
Secondly, whole lot of complexities are eliminated, arbitrary data can't be sent and received. Finally, the tool output are prompts to the model too, so you can leverage the output for better accuracy, which you can't do with general purpose apis.
[1] https://github.com/swagger-api/swagger-petstore/blob/master/...
hn_throwaway_99•6mo ago
0x457•6mo ago
hn_throwaway_99•6mo ago
So one real beauty of AI is that it is so good at taking "semi structured" data and structuring it. So perhaps I'm missing something, but I don't see how MCP benefits you over existing API documentation formats. It seems like an "old way" of thinking, where we always wanted to define these interoperation contract formats and protocols, but a huge point of AI is you shouldn't really need any more protocols to start with.
Again, I don't know all the ins and outs of MCP, so I'm happy to be corrected. It's just that whenever I see examples like in the article, I'm always left wondering what benefit MCP gives you in the first place.
vkazanov•6mo ago
More focused training -> more reliable understanding in LLMs.
Zigurd•6mo ago
lgas•6mo ago
hn_throwaway_99•6mo ago
Any human brainspace needed to even think about MCP just seems like it goes against the whole raison d'être of AI in that it can synthesize and use disparate information much faster, more efficiently, and cheaper than a human can.
floatrock•6mo ago
striking•6mo ago
ath_ray•6mo ago
You can use OpenAPI as well. With MCP however, there's an aspect of AI-nativity that MCP offers that reifies patterns that show up in building integrations that helps building and adoption (Tools, Prompts, Resources etc). It's a different layer of abstraction. There's some things like Sampling that I cannot find an OpenAPI equivalent of easily.
I definitely barely scratched the surface with my example, but it's true that most MCP Servers I have seen and used are basic REST endpoints exposed as tool calls.
That said, the MCP server layer has some design considerations as well, since it's a different layer of abstraction from a REST API. You may not want to expose all the API endpoints, or you may want to encode specific actions in a way that is better understood by an LLM rather than an application that parses OpenAPI.