HN Reader

I always say this whenever anyone asks about whether something is "just hype". One day I will write a blog post on it. Long story short: every piece of new tech is "just hype" until the surrounding ecosystem is built for it. Trains are just hype until you cover the country in railway lines. Telephony is just hype until everyone has a telephone. Email is just hype until everyone has a personal computer (and a reason to sit in front of it every day).

Typically, in these kinds of developments there are two key things that need to appear at the same time: 1. Ubiquitous hardware, so e.g. everyone buys a car, or a TV, or a toaster. 2. An "interface" (whether that's a protocol or a UI or an API or a design standard) which is hyper low cognitive load for the user e.g. the flush button on a toilet is probably the best example I've ever seen, but the same can be said for the accelerator + brake + steering wheel combo, or indeed in digital/online it's CSV for me, and you can also say the same about HTTP like this article does.

Obviously these two factors feed into each other in a kind of feedback loop. That is basically what the role of "hype" is, to catalyse that loop.

I don't want to sound like a skeptic, but I see way more people talking about how awesome MCP is rather than people building cool things with it. Reminds me of blockchain hype.

MCP seems like a more "in-between" step until the AI models get better. I imagine in 2 years, instead of using an MCP, we will point to the tool's documentation or OpenAPI, and the AI can ingest the whole context without the middle layer.

The author is missing the bit that the LLM provides: automatically mapping input parameters to things the user wants to do, and responses to the way the UI displays them.

Take out the LLM and you're not that far away from existing protocols and standards. It's not plugging your app into any old MCP and it just works (like the USB-C example).

But, it is a good point that the hype is getting a lot of apps and services to offer APIs in a universal protocol. That helps.

It's articles like this that tell you we're close to peak hype. There's nothing revolutionary about a text encoding plus a schema. SOAP could do this 20 years ago.

This is well written and fun. Thanks OP!

Now I am excited by MCP and would be all in except security.

Security is a huge issue.

Forget AI and imagine a system where you call APIs and you get both data and JS. And that JS executes at global scope with full access to other APIs. And so do all the other MCP servers. Furthermore the MCP server may go to arbitrary Web pages and download JS. And that JS e.g. from a strangers Github issue or Web search gets executes with full API privileges.

    <cute animal interject> This isn't something MCP can fix. It is built into the dice rolling nature of LLMs. Turning predictions into privileged executions. And those dice can be loaded by any MCP server.

Or imagine surfing the Web using a 2001 browser with no protections against cross domain scripting. Then having a page where you choose what init scripts to run and then it cascades from there. You are logged into your bank at the time!

This is what worries me. It's not USBC. It's sort of USBC but where you are ordering all your peripherals from Amazon, Ali express and Temu and the house is made of tinder.

> "The author discovers API's/JSON RPC"

I'm too young to be posting old_man_yells_at_cloud.jpg comments...

The author glosses over some practical realities. Just because something can be repurposed doesn't mean it should be. MCP was designed with specific assumptions about how AI models consume and process information. Using it as a general plugin system might work, but you'd likely hit limitations around things like authentication, real-time communication, or complex data flows that weren't priorities for the AI use case.

Seems like we're just currently in the top-right of this comic https://xkcd.com/2044/

I believe Microsoft's usual "Embrace, Expand, Extinguish" strategy is at work here. For system stability and security reasons, you wouldn't actually want agents to dynamically discover tools without proper governance. Alternatives like PydanitcAI are lost in this steady MCP noise maintained by Microsoft - their "Embrace" phase for MCP, declared during Build 2025 event. Anthropic released this open standard with weak tooling and no governance for the specs, making it easy for Microsoft to dominate.

The next step would be Microsoft attempting to make their registry the de facto choice for developers and extending with Windows-specific verbs.

Then, by controlling what's considered "secure", they can marginalize competitors.

If MCP gets used this way I see big trouble when people hardcode stuff and then the provider updates the endpoints. MCP does not have versions as the list-tools is a living document, you are supposed to fetch and read the current version. AI would be totally fine with it because it would be able to reason the change and adapt, but the hardcoded app is going to break badly.

For those who don't read things on Substack

http://archive.today/OUymS

Where do I get started with MCP? I’m all in, but kinda…confused?

A REST API makes sense to me…but this is apparently significantly different and more useful. What’s the best way to think about MCP compared to a traditional API? Where do I get started building one? Are there good examples to look at?

Interoperability is, and always was, the hardest part of programming systems together. It's telling that the ai tooling needed sustained non ai effort to expose the interfaces via MCP (or ws-* or rest or an enterprise service bus or xml or CORBA or EJB or...)

... MCP is almost literally just a JSON schema and a "yo, this stuff exists" for AI. It is great to have it standardised and we're all very thankful not to be using XML but there just isn't that much there.

MCP is fulfilling the promise of AI agents being able to do their own thing. None of this is unintended, unforeseen or particularly dependent on the existence of MCP. It is exciting, the fact that AI has this capability captures the dawn of a new era. But the important thing in the picture isn't MCP - it is the power of the models themselves.

Bret Victor had an old video where he talked about a world in which computers very organically figured out how to interoperate. MCP feels like the first realization of that idea.

>What if it's just "a standardized way to connect AI models literally anything to different data sources and tools"?

Then you aren't exploring a novel concept, and you are better served learning about historical ways this challenge has been attempted rather than thinking it's the first time.

Unix pipes? APIs? POSIX? Json? The list is endless, this is one of the requirements that you can identify as just being a basic one of computers. Another example is anything that is about storing and remembering information. If it's so foundational, there will be tools and protocols to deal with this since the 70s.

For the love of god, before diving into the trendy new thing, learn about he boring old things.

Universal but insecure

I don’t want to undermine the author’s enthusiasm for the universality of the MCP. But part of me can’t help wondering: isn’t this the idea of APIs in general? Replace MCP with REST and does that really change anything in the article? Or even an Operating System API? POSIX, anyone? Programs? Unix pipes? Yes, MCP is far simpler/universal than any of those things ended up being — but maybe the solution is to build simpler software on good fundamental abstractions rather than rebuilding the abstractions every time we want to do something new.

I agree with the article, and I love how the author is (mis-)using MCP. I just want to rephrase what the accident actually is.

The accident isn't that somehow we got a protocol to do things we couldn't do before. As other comments point out MCP (the specificaiton), isn't anything new or interesting.

No, the accident is that the AI Agent wave made interoperability hype, and vendor lock-in old-fashioned.

I don't know how long it'll last, but I sure appreciate it.

> What if you just... removed the AI part?

Maybe I'm not fully understanding the approach, but it seems like if you started relying on third-party MCP servers without the AI layer in the middle, you'd quickly run into backcompat issues. Since MCP servers assume they're being called by an AI, they have the right to make breaking changes to the tools, input schemas, and output formats without notice.

Lowering the bar to integrate and communicate is what has historically allowed technology to reach critical mass and enabled adoption. MCP is an evolution in that respect and shouldn’t be disregarded.

We had a non technical team member write an agent to clean up a file share. There are hundreds of programming languages, libraries, and apis that enabled that before MCP but now people don’t even have to think about it. Is it performant no, is it the “best” implementation absolutely not. Did it create enormous value in a novel way that was not possible with the resources, time, technology we had before 100%. And that’s the point.

Can someone help me find an actual explanation of what MCP does? The official MCP documentation completely fails at explaining how it works and what it does. For example the quick start for server developers[1] doesn’t actually explain anything. Sure in the Python examples they add @mcp annotations but WHAT DOES IT DO? I feel like I’m going crazy reading their docs because there’s nothing of substance in there.

Let’s assume I want to write an MCP HTTP server without a library, just an HTTP handler, how do I do it? What’s its schema? If I want to call an MCP server from curl what endpoint do I call? Can someone help me find where this is documented?

[1]: https://modelcontextprotocol.io/quickstart/server

While reading this, the old ARexx (Amiga Rexx) popped into my head. It was a scripting language that in itself wasn't very noteworthy. However, it also made it easy for applications to expose functionality through an ARexx port. And again, offering up an API itself isn't noteworthy either. But it shipped by default in the system and if an application wanted to open itself up for scripting, ARexx was the natural choice. As a result, a ton of applications did have ARexx ports and there was a level of universality that was way ahead of its time.

Come to think of it - I don't know what the modern equivalent would be. AppleScript?

So much scepticism in the comments. I spent last week implementing an MCP server and I must say that "well-designed" is probably an overstatement. One of the principles behind MCP is that "an MCP server should be very easy to implement". I don't know, maybe it's a skill issue but it's not that easy at all. But what is important imo, is that so many eyes are looking in one direction right now. That means, it has good chances to have all the problems to be solved very quickly. And second, often it's so hard to gather a critical mass of attention around something to create an ecosystem but this is happening right now. I wish all the participants patience and luck)

Although it has a benefit that it is possible to use like that (e.g. in case you do not have a better system), I think it isn't the best way to do. USB, HTTP, MCP, etc have many problems, despite whatever benefit they may have (including unintentional ones).

MCP works for small, well defined actions (like examples in the article), but enterprise APIs can have hundreds/thousands of endpoints/schemas for different concepts and variations of operations.

For example how would you MCP Google Ads rpc API https://developers.google.com/google-ads/api/reference/rpc/v... so that LLM and user will understand that? Seems like we can't escape complexity.

Agents (presumably) increase the demand for APIs and if those APIs as well as already existing APIs get exposed as MCPs then I can see it.

It is dependent on agents actually creating new demand for APIs and MCP being successful as a way to expose them.

I wonder how this interoperability hype in the industry, induced by MCPs, will affect companies where the lack of interoperability is almost a moat.

I remember when I first interacted with Marketo and I was wondering why people even bother trying to use this tool just to learn that Marketo has the best integration with Salesforce and thus, it’s almost a certainty that as you scale you’ll get to use it.

Salesforce in particular, relies a lot on the vendor ecosystem built on a platform that is so painful to inter operate with.

I’m very curious to see what effect this will have to them.

> emotional support portable fan

I can't be the only person that non-ironically has this.

> The protocol doesn't judge your life choices. This brings me to something I discovered about MCP (Model Context Protocol) while trying to make my calendar app order takeout. Stay with me here.

What was that character in “South Park” that has a hand puppet? (White noise, flatline sound)

I love the article & the protocol. However, MCP reminded me (somewhat) of microservices & SOA. Are we creating failure vectors nightmare? Or, is it, because of agents, we can gracefully increase reliability?

Anyone else feel like this article was written with ChatGPT

Yes, I'm old. Old enough to remember the MCP when he was just a chess program! He started small, and he'll end small!

So does that mean it’s good to integrate mcp with agentic ai

Is this basically the XML/RSS/semantic web of this tech wave?

I know this is nit-picky and not really relevant to the actual meat of the story, but a toaster (outside of a gag gift or gimmick) cannot run on USB-C since your typical toaster draws ~1kW and USB-C power spec tops out at 240W.

"Want your AI agents to respond like peons from Warcraft 3 when you assign them a task?" -- I'd rather be sailing.

I've thought of this as well but in reality, aren't MCP servers mostly just clients for pre existing APIs?

For example, the Kagi MCP server interacts with the Kagi API. Wouldn't you have a better experience just using that API directly then?

On another note, as the number of python interpreters running on your system increases with the number of MCP servers, does anyone think there will be "hosted" offerings that just provide a sort of "bridge" running all your MCP servers?

This all starting to look like autonomous driving. We are nowhere near solving it but everybody acts like it's here.

This isn't a snide comment, I am legitimately asking. I don't understand the difference between MCP and REST. I know there are differences because I've used it a little. I mean, like, on an existential level. Why isn't it just REST? What parts do MCP give us that REST doesn't?

I guess I’m finally old enough to become old-man-yelling-at-cloud.

I’m convinced that the only reason why MCP became a thing is because newcomers weren’t that familiar with OpenAPI and other existing standards, and because a protocol that is somehow tied to AI (even though it’s not, as this article shows) generates a lot of hype these days.

There’s absolutely nothing novel about MCP.

Offtopic: The article reads very much like it's chatgpt generated. But it's not surprising giving the subject matter. I just dislike how a computer tries to be entertaining and uses this default "voice" when writing anything. I hope there will be some way to personalize the output text, so it will be correct, but not soulless.

I thought MCPs just ‘figured out’ using docs how to call a program’s API. Won’t it matter that many APIs just suck?

Yup. Makes sense. The biggest value of MCP is that everyone is using MCP. This too is not a new insight.

Omg I wish people would just shut up about mcp already.

It's not magic, it's just smashing tool descriptions into your prompt, and the implementation sucks for various reasons, including there being no standard for tool use tags, nor the mcp spec including a common way of handling function call responses.

It's literally just "json into prompt & then it's all you buddy!" batteries NOT included, lmao

There's a reason no one uses cigarette lighters in cars anymore. If you actually try to use a cigarette lighter in a modern car, you'll likely melt your dashboard. They don't make them for that purpose anymore.

before we just figured out apis ,read some docs ,guessed and moved on... now apis gotta work for llms they don't read anything they just parse ,so standardising shifts... from neat docs to explainable api specs. schema + inputs + reflection + docstrings + specs + X . else agent just skips it. we are not only the consumer now

MCP over stdio

MCP over SSE

MCP over streamable HTTP

Authorization? Hahaha nah just put a token in your config file

Actually never mind.

Let's add OAuth...

Oh wait why are 90% of the server still using studio

Oh no

Let's deprecate SSE now

APM looks interesting, would love to try it out.

Oh boy, if only our personal AI assistants could be as reliable as a good old-fashioned pizza run by the CEO. The irony is delicious - we're moving towards universal plugins not because of some grand vision, but because everyone's desperate to make sure their AI doesn't go on an energy-saving nap mid-task.

It's almost poetic how we're now incentivizing interoperability simply because our digital buddies have to eat (or rather, drink) to stay awake. Who would've thought that the quest for connectivity would be driven by the humble Watt hour?

I guess when it comes down to it, even AI needs a good power-up - and hopefully, this time around, the plugins will stick. But hey, I'll believe it when my assistant doesn't crash while trying to order takeout.

what Anthropic did right with MCP that Google didn't with A2A?

So does that mean mcp is good to integrate along with Agentic AI

So does that mean mcp is good to integrate along with Agentic AI

>P.S. If you build an MCP server that makes your computer emit the smell of fresh bread, we need to talk.

https://news.ycombinator.com/item?id=29225777

DonHopkins on Nov 15, 2021 | parent | context | favorite | on: Xerox scanners/photocopiers randomly alter numbers...

The iSmell developers were hoping to make money the same way, by selling big smell combination pack cartridges that you have to entirely replace after any one of the smells ran out.

https://en.wikipedia.org/wiki/ISmell

>The iSmell Personal Scent Synthesizer developed by DigiScents Inc. is a small device that can be connected to a computer through a Universal serial bus (USB) port and powered using any ordinary electrical outlet. The appearance of the device is similar to that of a shark’s fin, with many holes lining the “fin” to release the various scents. Using a cartridge similar to a printer’s, it can synthesize and even create new smells from certain combinations of other scents. These newly created odors can be used to closely replicate common natural and manmade odors. The cartridges used also need to be swapped every so often once the scents inside are used up. Once partnered with websites and interactive media, the scents can be activated either automatically once a website is opened or manually. However, the product is no longer on the market and never generated substantial sales. Digiscent had plans for the iSmell to have several versions but did not progress past the prototype stage. The company did not last long and filed for bankruptcy a short time after.

This Wired Magazine article is a classic Marc Canter interview. I'm surprised they could smell the output of the iSmell USB device over the pungent bouquet from all the joints he was smoking:

You've Got Smell!

https://web.archive.org/web/20160303130915/https://www.wired...

>DigiScent is here. If this technology takes off, it's gonna launch the next Web revolution. Joel Lloyd Bellenson places a little ceramic bowl in front of me and lifts its lid. "Before we begin," he says, "you need to clear your nasal palate." I peer into the bowl. "Coffee beans," explains Bellenson's partner, Dexster Smith. […]

>"You know, I don't think the transition from wood smoke to bananas worked very well." -Marc Canter

The failed quest to bring smells to the internet (thehustle.co)

https://thehustle.co/digiscents-ismell-fail

https://news.ycombinator.com/item?id=17476460

DigiScent had a booth at the 1999 Game Developers Conference, with scantily dressed young women in skunk costumes.

I told them about a game called "The Sims" I had been working on for a long time, and was hoping to finish and release some time soon.

They unsuccessfully tried to convince me to make The Sims support the iSmell, and even gave me a copy of the SDK documentation, because they thought it would enrich the player's experience of all those sweaty unwashed sims, blue puddles of piss on the floor, stopped up toilets in the bathroom, and plates of rotting food with flies buzzing around on the dining room table.

HTTP: A (Deliberately) Universal Plugin System

The real accident is that the prompts became a programming language. I don't think the ML Engineers set out to create a general purpose programming language.

A2A (agent 2 agent) mechanism is an another accidental discovery for the interoperability across agent boundaries

Can someone link to this supposed toaster with DP-alt mode? That supposedly runs on 240W? (Max PD power)

Is it some kind of CORBA?