Hacker News Reader

Comment by abtinf | Hacker News Reader

> The way we like to think about MCP at this point is that it should be much closer to OpenAPI with intelligent tool discovery. That means tools should return structured data and tools should be discoverable by their documentation and description.

OpenAPI is “intelligent tool discovery” (whatever that is). OpenAPI literally “returns structured data” and is “discoverable by their documentation and description.”

Just once, I’d like to see someone explain MCP in terms that suggest they have any idea what they are talking about.

View on HN

I do sometimes wonder about the value of the whole MCP spec rather than just adding some semi-standard attributes to OpenAPI specs to make them more LLM consumable.

There were OSS implementations of that but MCP came with anthropic backing and won. Like VHS and Betamax, sometimes you just have to accept that marketing wins over engineering purity.

I think it's fair to say I know quite a bit about MCP (I built a company on it) so I'll take a crack at this. TLDR: MCP is an Oauth protocol now

MCP started out as this sudo browser replacement protocol for AI integrations. Similar to how a browser opens tabs and loads in JS, the idea was that MCP hosts load in MCPs and interact with them that way. Thus the original spec shipped as a stateful server client protocol with prompts, resources, a bunch of other stuff... and tools (the only thing anyone really ended up using). If you want to learn more about the original idea behind it, the creators did a pretty good podcast where they go through the conception and their design partnership with the Zed guys.

It became pretty clear early on that that way people wanted to use it was basically "I heard if I download this thing called an MCP the AI can manage my Jira tickets". so it's been almost 2 years now of rolling back all the opinions of the original protocol (statefulness, esoteric features) and bringing it closer to OpenAPI + JSONRPC + OAuth. Since the July spec release, you will start seeing alot more of this: https://redocly.com/docs/realm/content/api-docs/openapi-exte...

The biggest "win" of MCP is that the hype behind it let the Oauth guys swoop and use it to formalize a bunch of Oauth specs into a coherent story for API auth.

Hey, I just wanted to say thank you for explaining MCP in those terms, it finally makes sense to me now!

Seriously, it just makes no sense.

https://chatgpt.com/share/6abd1842-cd34-83e8-997e-55c8bc23cd...

Don't be a meat proxy

Having built out MCP functionality for actual use cases for a small company, the big gotchas for us that can't be handled with "just an API" (putting aside the auth flow thing) have so far been (a) fully custom UI pieces in GUI clients (for example, media embeds with custom rendering) and (b) having the ability to put a user-facing hard stop in the loop for some interactions.

Part (a) in particular is pretty prominent for us since our uses cases are all about video, and having "just" an iframe URL to supply, with no other interaction with the model/turns, would give a pretty janky and unpleasant experience if Claude/ChatGPT even allowed it to embed.

"Just use OpenAPI" doesn't handle the question of having a single well-defined OAuth flow that will work with desktop clients across the board, as well as various gotchas like rendering embedded widgets that will use that OAuth flow, elicitations for user decision points outside of the model control, and other such things outside of the API round trip process itself.

Reply on news.ycombinator.com