I don't understand your point. Some of those things were buzzwords, some were impossible dreams, some changed the way the web works completely. Are you just saying that the future is unknown?
No. What they are saying is best said with a quote from Battlestar Galactica:
> All of this has happened before, and all of this will happen again.
”It” here being the boom and inevitable bust of interop and open API access between products, vendors and so on. As a millenial, my flame of hope was lit during the API explosion of Web 2.0. If you’re older, your dreams were probably crushed already by something earlier. If you’re younger, and you’re genuinely excited about MCP for the potential explosion in interop, hit me up for a bulk discount on napkins.
And then, there are "architecture astronaut"s dreaming of an entire internet of MCP speaking devices - an "internet of agents" if you will. That is now requiring a separate DNS, SMTP, BGP etc. for that internet.
I think battlestar Galactica must be quoting one of the Eddas. I've only read if it from Borges in Spanish, but Conner the same meaning: "Estas cosas han pasado. Estas cosas también pasarán."
I'm older and would like a discount please. The "this time it's different" energy is because assuming a human can interact with the system, and that vision models can drive a gui, who cares if there's an actual API, just have the AI interact with the system as if it was coming in as a human.
What's the point of stating the obvious if the obvious won't change anything? Things evolve. Winners win and losers lose. Change is constant. And? Does that somehow mean there's nothing to see here and we should move on?
No, things can change but we programmers tend to see everything as a technical problem, and assume that if only we can find a good technical solution we can fix it. But the problem isn’t technical – the APIs were shut down because consumer tech is governed by ads, which are not part of APIs (or would be trivial to remove). You have surely noticed that APIs are alive and well in enterprise, why? Because they have customers who pay money, and API access does not generally break their revenue stream (although even there some are skittish). As mere ”users” our economic function in consumer tech is to provide data and impressions to advertisers. Thy shall not bypass their sidebar, where the ads must be seen.
Nowadays the shutdown is not just of APIs but even anti-scraping, login walls, paywalls, fingerprinting, and so on and so forth. It’s a much more adversarial landscape today than during Web 2.0. When they threw copyright in the trash with the fair use loophole for AI, that obviously causes even more content lockdown panic. And in the midst of this giant data Mexican standoff, people are gonna take down their guns and see the light because of a new meta—API protocol?
I take their point to be that the underlying incentives haven't changed. The same forces and incentives that scuttled those things are likely to scuttle this as well.
I actually disagree with the OP in this sub-thread:
> "No, the accident is that the AI Agent wave made interoperability hype, and vendor lock-in old-fashioned."
I don't think that's happened at all. I think some interoperability will be here to say - but those are overwhelmingly the products where interoperability was already the norm. The enterprise SaaS that your company is paying for will support their MCP servers. But they also probably already support various other plugin interfaces.
And they're not doing this because of hype or new-fangledness, but because their incentives are aligned with interoperability. If their SaaS plugins into [some other thing] it increases their sales. In fact the lowering of integration effort is all upside for them.
Where this is going to run into a brick wall (and I'd argue: already has to some degree) is that closed platforms that aren't incentivized to be interoperable still won't be. I don't think we've really moved the needle on that yet. Uber Eats is not champing at the bit to build the MCP server that orders your dinner.
And there are a lot of really good reasons for this. In a previous job I worked on a popular voice assistant that integrated with numerous third-party services. There has always been vehement pushback to voice assistant integration (the ur-agent and to some degree still the holy grail) because it necessarily entails the service declaring near-total surrender about the user experience. An "Uber Eats MCP" is one that Uber has comparatively little control over the UX of, and has poor ability to constrain poor customer experiences. They are right to doubt this stuff.
I also take some minor issue with the blog: the problem with MCP as the "everything API" is that you can't really take the "AI" part out of it. MCP tools are not guaranteed to communicate in structured formats! Instead of getting an HTTP 401 you will get a natural language string like "You cannot access this content because the author hasn't shared it with you."
That's not useful without the presence of a NL-capable component in your system. It's not parseable!
Also importantly, MCP inputs and outputs are intentionally not versioned nor encouraged to be stable. Devs are encouraged to alter their input and output formats to make them more accessible to LLMs. So your MCP interface can and likely will change without notice. None of this makes for good API for systems that aren't self-adaptive to that sort of thing (i.e., LLMs).
