But the way I see it, AI agents created incentives for interoperability. Who needs an API when everyone is job secure via being a slow desktop user?
Well, your new personal assistant who charges by the Watt hour NEEDS it. Like when the CEO will personally drive to get pizzas for that hackathon because that’s practically free labor, so does everyone want everything connected.
For those of us who rode the API wave before integrating became hand-wavey, it sure feels like the world caught up.
I hope it will last, but I don’t know either.
I tried to find a rebuttal to this article from Slack, but couldn't. I'm on a flight with slow wifi though. If someone from Slack wants to chime in that'd be swell, too.
I've made the argument to CFOs multiple times over the years why we should continue to pay for Slack instead of just using Teams, but y'all are really making that harder and harder.
[0]: https://www.reuters.com/business/salesforce-blocks-ai-rivals...
As it is, I'm going to propose that we move more key conversations outside of slack so that we can take advantage of feeding it into ai. It's a small jump from that to looking for alternatives.
Getting indexed by AI crawlers appears to be the new equivalent to getting indexed by search engines.
The reality is that Slack isn’t that sticky. The only reason I fended off the other business units who've demanded Microsoft Teams through the years is my software-engineering teams QoL. Slack has polish and is convenient but now that Slack is becoming inconvenient and not allowing me to do what I want, I can't justify fending off the detractors. I’ll gladly invest the time to swap them out for a platform that respects our ownership and lets us use our data however we need to. We left some money on the table but I am glad we didn’t bundle and upgrade to Slack Grid and lock ourselves into a three-year enterprise agreement...
The dedicated voice/video channels are great for ad-hoc conversations when remote and a lot better than Slack’s huddles. They’re like dedicated remote meeting rooms except you’re not limited by office space.
Granted, my Discord usage been relatively limited, but what "gaming stuff"? In the servers unrelated to gaming I don't think I see anything gaming related, but maybe I'm missing something obvious.
Super happy with it. No bullshit upgrades that break your way of working. Utilitarian approach to everything, the basics just work. Still has some rough edges, but in a workhorse kind of way.
Endorse.
True, and if you're the only one sitting on the data and using it, then what you say is true.
The moment you use another platform, entering agreements of terms of service and more, it stops being "your and/or your company's data" though, and Slack will do whatever they deem fit with it, including preventing you from getting all of the data, because then it gets easier for you to leave.
Sucks, yeah, but it is the situation we're in, until lawmakers in your country catch up. Luckily, other jurisdictions are already better for things like this.
But now they're actively making it more difficult for people like me to say "engineers like it more" and that be a compelling-enough argument.
I think you'll see this everywhere. LLMs mean "normal" people will suddenly see computers the way we do and a lot of corporate leadership just isn't intuitively prepared for that.
There are no new incentives for interoperability. Compare that were already providing API access added MCP servers of varying quality.
The rest couldn't care less, unless they can smell an opportunity to monetize hype
Though the general API lockdown was started long before that, and like you, I’m skeptical that this new wave of open access will last if the promise doesn’t live up to the hype.
In practice, the distinction is little more than the difference between different HTTP verbs, but I think there is a real difference in what people are intending to enable when creating an MCP server vs. standard APIs.
To this point, GUIs; going forward, AI agents. While the intention rhymes, the meaning of these systems diverge.
the APIs that used to be free and now aren't were just slightly ahead of the game, all these new MCP servers aren't going to be free either.
The APIs of old were about giving you programmatic access to publicly available information. Public tweets, public Reddit posts, that sort of thing. That's the kind of data AI companies want for training, and you aren't getting it through MCP.
(The mashup hype was incredible, btw. Some of the most ridiculous web contraptions ever.)
(I hereby claim the name "DJ MCP"...)
Mcp is a fad, it’s not long term tech. But I’m betting shoveling data at llm agents isn’t. The benefits are too high for companies to allow vendors to lock the data away from them.
One that won't be supported by any of the big names except to suck data into their walled gardens and lock it up. We all know the playbook.
I'd bet that while "shoveling data at llm agents" might not be a fad, sometime fairly soon doing so for free while someone else's VC money picks up the planet destroying data center costs will stop being a thing. Imagine if every PHP or Ruby on Rails, or Python/Django site had started out and locked themselves into a free tier Oracle database, then one day Oracle's licensing lawyers started showing up to charge people for their WordPress blog.
> 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.
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 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).
In all seriousness though, I think HN has a larger-than-average amount of readers who've worked or studied around semantic web stuff.
There's a shocking overlap of GPU-slinging tech-bros hyping both. Crypto-bros turned LLM-experts out of necessity when mining crypo on their rigs became unprofitable.
I'm just baffled no software vendor has already come up with a subscription to access the API via MCP.
I mean obviously paid API access is nothing new, but "paid MCP access for our entreprise users" is surely on the pipeline everywhere, after which the openness will die down.
Heck, if AIs are at some point given enough autonomy to simply be given a task and a budget, there'll be efforts to try to trick AIs into thinking paying is the best way to get their work done! Ads (and scams) for AIs to fall for!
We're already there, just take a look at the people spending $500 a day on Claude Code.
Optionality will kill adoption, and these things are absolutely things you HAVE to be able to play with to discover the value (because it’s a new and very weird kind of tool that doesn’t work like existing tools)
Perhaps but we see current hypes like Cursor only using MCP one way; you can feed into Cursor (eg. browser tools), but not out (eg. conversation history, context etc).
I love Cursor but this "not giving back" mentality originally reflected in it's closed source forking of VS Code leaves an unpleasant taste in the mouth and I believe will ultimately see it lose developer credibility.
Lock-in still seems to be locked in.
In my experience Claude and Gemini can take over tool use and all we need to do is tell them the goal. This is huge, we always had to specify the steps to achieve anything on a computer before. Writing a fixed program to deal with dynamic process is hard, while a LLM can adapt on the fly.
IFTTT was announced Dec. 14, 2010 and launched on Sept. 7. 2011.
Zapier was first pitched Sept. 30, 2011 and their public beta launched May 2012.
Do we really not having anything coming close to the usefulness of Yahoo Pipes yet? What would a modern alternative look like and how would it work? Someone has to thinking about this.
> Do we really not having anything coming close to the usefulness of Yahoo Pipes yet?
I don't know of anything. There's some new products I saw heavily promoted on LinkedIn, but at first glance they feel like IFTTT with a shiny coat of paint.
> What would a modern alternative look like and how would it work?
At this point I think ComfyUI or the node editor in Blender would be the best; they're oriented for different kinds of workflows, but UIs of both are excellent in their own ways, and the rest is a matter of implementing the right blocks.
Previously, many companies gated these APIs but with the MCP AI hype they are incentivized to expose what you can achieve with APIs through an agent service.
Incentives align here: user wants automations on data and actions on a service they are already using, company wants AI marketing, USP in automation features and still gets to control the output of the agent.
Why would they be incentivized to do that if they survived all the previous hype waves and still have access gated?
> user wants automations on data and actions on a service they are already using,
How many users want that? Why didn't companies do all this before, since the need for automation has always been there?
Because they suddenly now don't want to be left out of the whole AI hype/wave.
Is it stupid? Yes. Can we still reap the benefits of these choices driven by stupid motivations? Also yes.
https://news.ycombinator.com/item?id=44405491 and https://news.ycombinator.com/item?id=44408434
(And we know that because there was a brief period in time where basics of spreadsheets and databases were part of curriculum in the West and people had no problem with that.)
> It (the main benefit?) is the LLM itself, if it knows how to wield tools.
LLMs and their ability to use tools are not a benefit or feature that arose from MCP. There has been tool usage/support with various protocols and conventions way before MCP.
MCP doesn't have any novel aspects that are making it successful. It's relatively simple and easy to understand (for humans), and luck was on Anthropic's side. So people were able to quickly write many kinds of MCP servers and it exploded in popularity.
Interoperability and interconnecting tools, APIs, and models across providers are the main benefits of MCP, driven by its wide-scale adoption.
> Want it to order coffee when you complete 10 tasks? MCP server.
With a trip through an LLM for each trivial request? A paid trip? With high overhead and costs?
Before, "add a public API to this comic reader/music player/home accounting software/CD archive manager/etc." would be a niche feature to benefit 1% of users. Now more people will expect to hook up their AI assistant of choice, so the feature can be prioritized.
The early MCP implementations will be for things that already have an API, which by itself is underwhelming.
You would think Apple would have a leg up here with AppleScript already being a sanctioned way to add scriptable actions across the whole of macOS, but as far as I can tell they don't hook it up to Siri or Apple Intelligence in any way.
So how does MCP help with this?
An MCP API dodges all of that. You still need some data structures but beyond that you don't think too hard, just write some docs - no fancy HTML or SDKs needed. MCP is a desktop-first API so auth mostly stops being an issue. Most importantly, if you need to change anything you can, because the LLM will just figure it out, so you're way less product constrained.
I always imagined software could be written with a core that does the work and the UI would be interchangeable. I like that the current LLM hype is causing it to happen.
If I have a app who's backend needs to connect to, say, a CRM platform - I wonder if instead of writing APIs to connect to Dynamics or Salesforce or Hubspot specifically, if there's benefit in abstracting a CRM interface with an MCP so that switching CRM providers later (or adding additional CRMs) becomes easier?
"Okay but. But. What if you just... removed the AI part?
What if it's just "a standardized way to connect literally anything to different data sources and tools"?"
(which had struck out text 'AI models' in between 'connect' and 'literally')
But… you don’t really need to pretend you’re an LLM, you can just get the data using the same interface as a model would.
Have a look at the Filesystem example MCP server - https://github.com/modelcontextprotocol/servers/blob/main/sr.... It has a collection of Tools - read_file, read_multiple_files, write_file, etc.
The LLM uses MCP to learn what tools the server makes available; the LLM decides when to use them. (The process is a little more complicated than that, but if you're just trying to call tools without an LLM, those parts aren't really important.) If you ask the LLM, "Find all files with an asterisk," it might deduce that it can use the search_files tool provided by that MCP to gain the needed context, invoke that tool, then process the results it returns. As an engineer, you can just call search_files if you know that's what you want.
The thing that surprises me is with MCP we have shirked all of the existing tools around OpenAPI specs, OIDC, etc. We could have created a system where all 'services' expose a mcp.slack.com/definition endpoint or something that spit back a list of shortcut terms like send_message and a translation function that composes it into the correct HTTP API (what most MCP servers do). For security we could have had the LLM establish its identity via all our existing systems like OIDC that combine authentication and authorization.
In the system above you would not "install an mcp package" as in a code repo or server. Instead you would allow your LLM to access slack, it would then prompt you to login via OIDC and establish your identity and access level. Then it would grab the OpenAPI spec (machine readable) and the LLM focused shortcuts 'send_message', 'read_message', etc. LLM composes 'send_message Hello World' -> translates to HTTP POST slack.com/message or whatever and bob's your uncle.
If you wanted to do fancy stuff with local systems then you could still build your own server the same way we have all built HTTP servers for decades and just expose the mcp.whatever.com subdomain for discovery. Then skip OIDC or allow ALL or something to simplify if you want.
The MCP exposed API is there for anyone/anything to use, as long as you are able to understand how it works - by reading the natural language description of the exposed methods and their JSON input schemas. You could read this yourself and then use these methods in any way you choose.
Where LLMs come in is that they understand natural language, so in the case where the MCP client is an LLM, then there is automatic discovery and integration - you don't need to grok the MCP interface and integrate it into your application, but instead the LLM can automatically use it based on the interface description.
For those that don't remember/don't know, everything network related in Windows used to use their own, proprietary setup.
Then one day, a bunch of vendors got together and decided to have a shared standard to the benefit of basically everyone.
It feels like 2 or 3 companies have paid people to flood the internet with content that looks educational but is really just a sales pitch riding the hype wave.
Honestly, I just saw a project manager on LinkedIn telling his followers how MCP, LLMs and Claude Code changed his life. The comments were full of people asking how they can learn Claude Code, like it's the next Python.
Feels less like genuine users and more like a coordinated push to build hype and sell subscriptions.
People write those medium articles wanting engagement/clout/making it big/creating a brand.
The whole hype around AI replacing entire job functions does not have as much traction as the concept of using agents to handle all of the administrative stuff that connects a workflow together.
Any open source model that supports MCP can do it, so there’s no vendor lock in, no need to learn the setup for different workflow tools, and a lot of money saved on seats for expensive SaaS tools.
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.