alt.hn

5/22/2025 at 3:39:49 PM

MCP explained without hype or fluff

 https://blog.nilenso.com/blog/2025/05/12/mcp-explained-without-hype-or-fluff/

by captn3m0

5/22/2025 at 5:03:38 PM

Good point about the M x N problem reduction, but this glosses over a critical limitation. While MCP does turn integration complexity from M x N to M + N for the protocol layer, authentication and authorization remain stubbornly M x N problems.

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.

by thembones

5/23/2025 at 5:14:53 AM

> Each MCP server still needs to handle auth differently depending on what it's connecting to.

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.

https://docs.mcp.run/blog/2025/05/14/mcp-sso/

by nilslice

5/23/2025 at 5:11:21 AM

If PGP had evolved with better ergonomics, the world would be so different today. I should just be able to use one key or certificate everywhere, with a web of trust to help providers decide whether my key is authentic.

by soulofmischief

5/22/2025 at 7:12:56 PM

If the MCP is running on the user client side and only the llm is remote then possibly one can leverage the existing authentication infrastructure between enterprise IdP, browser, MCP and the enterprise target sites?

by heisenbit

5/22/2025 at 11:21:13 PM

Seems like you have identified a potential business need! If some component could simplify the auth similarly, that would presumably be very valuable. Could be an open source project, or a startup (or both).

by jononor

5/22/2025 at 6:31:06 PM

I imagine this will speed up the convergence of all servers towards oauth and totp

by nurettin

5/23/2025 at 1:03:39 AM

You still have different tokens for every site.

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.

by cruffle_duffle

5/22/2025 at 4:37:52 PM

The overload of GenAI related postings on here almost makes me look with nostalgy at the period when most of the posts were about some SQLite optimisation/use-case/weird trick....

by hansmayer

5/22/2025 at 5:53:36 PM

Can I interest you in a new Javascript framework?

by explorigin

5/22/2025 at 6:18:49 PM

Why yes, especially if it is "elegant", "easy to use" and of course "optimised for developer experience" :)

by hansmayer

5/22/2025 at 5:57:43 PM

Water found on Mars!

by dvh

5/22/2025 at 4:56:52 PM

Eternal September

by thm

5/22/2025 at 9:12:32 PM

In that era there were probably loads of people nostalgic about weird C memory use-cases not being talked about as much.

by virtouspapaya

5/22/2025 at 5:55:18 PM

This is a bit of hyperbole. Step back and look at the list of articles on the front page. You're going to see a lot of different things. It's not the overwhelming flood of Gen AI content that you're saying here. We got one guy who wrote his own music player for iOS. We got this other guy who's optimizing is OCR code. Another article talks about infrared contact lenses. And yeah there's going to be more AI stuff than there used to be, because that's what's going on right now in the field. But it's far from the only thing. Not by a long shot. The only reason you and I are conversing in this AI adjacent thread is because we both clicked on the link. The only difference between us is that I was actually interested in what this article had to say, but you're clearly not. And that's completely fair! But you make it sound like you're starved for non-AI content when there's a whole wealth of it on the front page. C'mon.

by fortyseven

5/22/2025 at 6:17:38 PM

On a deeper level, the complaint is about the meaninglessness of those many posts. It is supposed to be revolutionary tech, but every week, every week we are bombarded with these vague and mostly it seems incremental "improvements". People who post this stuff should wait up a bit and let us know when there is a real breakthrough. Or when the VC investors stop pumping in on the order of 200B USD into the magic oracle industry,only to generate a total of 10B pre-tax income for all the major AI companies combined.

by hansmayer

5/22/2025 at 5:49:45 PM

Yes, please bring back the blockchain posts. /s

<small>hmm, generative ai blockchain?...</small>

by tra3

5/22/2025 at 7:36:40 PM

We had Bored Ape, but what we really wanted was Infinite Monkeys.

by threetonesun

5/22/2025 at 4:37:45 PM

I keep waiting for someone to break character and admit that this is all an extended trolling campaign. People are actually connecting these autocompletes to APIs and giving credentials to take impactful external actions? Y'all are _insanely_ trusting.

by scubbo

5/22/2025 at 5:54:05 PM

I'm with you, but it makes for extremely impressive demos. And surprisingly useful day to day improvements.

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.

by tra3

5/22/2025 at 6:15:33 PM

Do you maintain a newsletter or take subscriptions in some other fashion? This is a refreshingly low-BS take and those are hard to come by, and I would be interested especially in Emacs integrations.

by throwanem

5/22/2025 at 8:12:05 PM

Sounds useful. However, I'd rather put deterministic code in control of the LLM than the LLM in control of deterministic code. And that's even before prompt injections.

by Yoric

5/23/2025 at 9:50:06 AM

you don't trust or untrust algorithms. like you said, they're just autocompletes. you quantify the risk and see if you have an appetite for it. any sane engineer won't just let an LLM loose, they'll build guardrails around it. If the solution involved untrusted external/human input the risk is much higher, but for a private system, there is only so much paranoia you can throw around before it turns into anthropomorphizing algorithms.

by notepad0x90

5/22/2025 at 3:59:59 PM

Can we not just point LLMs at OpenAPI documents and achieve the same result? All of the example functions in the article look like very very basic REST endpoints.

by nythroaway048

5/22/2025 at 4:33:07 PM

Exactly. We already have lots of standards for defining APIs (OpenAPI, GraphQL, SOAP if I'm showing my age, etc. etc.) Part of my original "wow this is magic" moment with AI came when OpenAI released some of their plugins and showed how you could just point it at an API spec and the LLM could just figure out, on its own, how to use it.

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.

by hn_throwaway_99

5/22/2025 at 4:41:50 PM

Well, one benefit is the precision and focus of the protocol that can be used to train/finetune LLMs.

More focused training -> more reliable understanding in LLMs.

by vkazanov

5/22/2025 at 4:57:23 PM

I hear you but what exactly about MCP is more precise or training-friendly than other approaches? I can think of at least one way that it isn't: MCP doesn't provide an API sandbox the way an Apigee or Mulesoft API documentation page could.

by Zigurd

5/23/2025 at 1:18:24 PM

There's no reason it couldn't.

by lgas

5/22/2025 at 5:17:12 PM

I understand what you're saying, but I'm still not clear why any of this should be necessary or is a benefit for LLMs. Another commenter mentioned that MCP saves tokens and is more compact. So what? Then just have the LLM do a one-time pass of a more verbose spec to summarize/minify it.

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.

by hn_throwaway_99

5/22/2025 at 7:03:03 PM

Don't forget HATEOAS if we're listing prior art of self-discoverable APIs!

by floatrock

5/22/2025 at 4:27:09 PM

You can, most MCP servers are just wrappers around existing SDKs or even rest endpoints.

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

by s900mhz

5/22/2025 at 4:32:28 PM

OpenAPI definitions are verbose and exhaustive. In MCPs you can remove a lot of extra material, saving tokens.

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/...

by pcwelder

5/22/2025 at 4:34:51 PM

So why can't the LLM just take the verbose OpenAPI spec, summarize it and remove the unnecessary boilerplate and cruft (do that once), and only use the summarized part in the prompt?

by hn_throwaway_99

5/22/2025 at 8:07:09 PM

There is probably an MCP for that

by 0x457

5/22/2025 at 4:09:00 PM

That’s basically what we did before MCP. And what (for example) langchain does.

It’s great to have a standard way to integrate tools but I can’t say I have much love for MCP specifically.

by hnlmorg

5/22/2025 at 5:18:46 PM

The docs are often pretty wrong. It's nice to formalize the glue in a server.

by striking

5/22/2025 at 4:38:09 PM

I found myself trying to explain MCP the other day. The simplest way I could put it for another developer:

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.

by Zaheer

5/22/2025 at 4:34:30 PM

It's cgi-bin for AI.

by mannyv

5/22/2025 at 4:50:08 PM

I think it's a beautiful comparison on many levels.

by egorfine

5/22/2025 at 5:00:24 PM

Waiting for the AI /cgi-bin/phf.

by ok123456

5/22/2025 at 5:31:50 PM

MCP is as revolutionary as JSON.

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.

by beernet

5/22/2025 at 5:43:28 PM

As in: "JSON was a huge deal, and this could also be a huge deal" or "Just use JSON"?

by emehex

5/22/2025 at 7:58:15 PM

MCP is bloated AI hype that basically solves nothing (the Langchain of 2025!). Typical tooling on top of tooling and the quintessential case of a problem looking for a solution. It's absolute garbage from just about any standpoint: architectural, security, elegance, etc. But my main point is that it solves nothing and there's nothing novel here. It's APIs talking to APIs that talk to other APIs. Wow, groundbreaking!

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
Like, I get it, it's hard to come up with new ways of solving some of these (or bringing them up from ~50% to 90% accuracy), but no one's going to use an AI agent when it confidently fakes data, it doesn't remember important stuff, or you gotta sit there and tweak a prompt for 30 minutes.

by dvt

5/22/2025 at 8:27:44 PM

MCP is pretty awesome for linking tools to LLMs with each not knowing about each other in advance. Coolest is linking a decompiler with MCP and then LLM then requests to decompile specific functions and give explanations of the assembly code https://www.youtube.com/watch?v=u2vQapLAW88

by kanwisher

5/22/2025 at 4:23:46 PM

Has anyone found good resources about dealing with authentication in MCP, especially about managing the oauth tokens locally?

by bootsmann

5/23/2025 at 1:11:37 AM

I haven’t really figured it out yet either. I think this protocol is pretty early in terms of support and tooling. They really seem to want you to connect locally and edit config files still.

Hopefully soon this stuff will get ironed out because yeah, auth is super important.

by cruffle_duffle

5/22/2025 at 4:22:49 PM

I feel like there's something wrong with me for not understanding the big leap with MCP and the proponents aren't helping.

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."

by huhkerrf

5/22/2025 at 5:14:30 PM

REST doesn't provide the documentation or the semantics of the interface. It's the API definition along with text on why to use it, when to use it, and how to use it. This is what is needed for a LLM to consume it. The documentation is a requirement. I have developed many MCP Servers, they are real and they provide me real value in my work every day.

by doug_durham

5/22/2025 at 8:23:51 PM

With how big some OpenAPI docs are the problem isn't "LLMs can't figure out OpenAPI documentation." it's that consuming OpenAPI documentation is extremely resource intensive. I've met openapi docs that make client generators choke just by being large.

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.

by 0x457

5/22/2025 at 4:45:48 PM

They are, like much of the GenAI-hype, simply a solution looking for a problem. That's why they need to explain it so much - it's more of a desperate convincing really...

by hansmayer

5/22/2025 at 6:33:17 PM

How so humans need to know about all this? Isn’t it the exact use case where the machines write all the code as it is machine to machine protocol and some of the machine involved are supposed to be phd level programmers.

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?

by mrtksn

5/22/2025 at 6:37:24 PM

> 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.

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.

by Yoric

5/22/2025 at 8:20:12 PM

I think MCP is pretty close to what LSP is.

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.

by 0x457

5/22/2025 at 4:09:08 PM

I know it’s in active discussion on GH, but I wish clients would solve (non-text) UIs from MCP servers rather soon. It would 10x the power of these chat extensions.

by thekodols

5/22/2025 at 4:13:50 PM

can you give an example of what you're talking about? do you mean not having a "chatbot" UI and instead sending a camera feed to your mcp client or something?

by anthonypasq

5/22/2025 at 4:41:48 PM

Here's someone experimenting with what I mean: https://github.com/idosal/mcp-ui

by thekodols

5/22/2025 at 5:06:18 PM

Is this sort of like how, when iPhone touch-screen came out, it allowed for dynamic regeneration of UI for each specific app instead of "hard coding" hardware inputs/buttons as the one interface to all apps? So here, AI can dynamically generate a context-dependent UI on the fly that can be interacted with, influenced by user input, API reponses etc?

by PKop

5/22/2025 at 4:01:41 PM

Why is there so much explaining to do for MCPs? There seem to be something seriously wrong with the way Anthropic is marketing it. It looks like the entire world is confused as to what it is.

by m3kw9

5/22/2025 at 7:26:07 PM

It's being made out to be something bigger/more important than what it is to create hype and investment interest. Is it incredibly useful? Yes. But it's not aliens landing on the front lawn of the White House offering us anti-gravity tech.

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.

[1] https://news.ycombinator.com/item?id=44065739

by rglover

5/22/2025 at 7:53:12 PM

To parent's point, your summary:

> 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.

by crystal_revenge

5/22/2025 at 8:13:54 PM

> 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.

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.

by rglover

5/22/2025 at 7:22:12 PM

Initially I took MCP to be some crazy new thing, but once I dug into it, it's really just a soft-standard for connecting a database, API, or other data source (e.g., a list of functions that can be called) to a vector database and then returning a response in a standardized JSON format.

It's basically RAG with a bit of sugar on top. What spooks me is how few people hyping MCP seem to understand that.

by rglover