Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP: An (Accidentally) Universal Plugin System

worksonmymachine.substack.com

Post reply on HN
Print view View original

241–250 of 366 posts

Re: MCP: An (Accidentally) Universal Plugin System

#241

Post by ramoz »

anon7000 wrote: post #234
ramoz wrote: post #222

Earlier quoted context omitted.

> Regardless of how good a model gets I don't think this is true. My Claude Code can: - open a browser, debug a ui, or navigate to any website - write a script to interact with any type of accessible api All without MCP. Within a year I expect there to be legitimate "computer use" agents. I expect agent sdks to take over llm apis as defacto abstractions for models, and MCP will have limited use isolated to certain pl…

> open a browser, debug a ui, or navigate to any website I mean, that’s just saying the same thing — at the end of the day, there’s are underlying deterministic systems that it uses

Yes my response was poorly oriented the parent comment

Re: MCP: An (Accidentally) Universal Plugin System

#242

Post by freeone3000 »

crucialfelix wrote: post #208
Mtinie wrote: post #196

Earlier quoted context omitted.

Minor chronological point but Zapier is an IFTTT-type glue provider. 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.

And to answer the obvious next question: yes, there is an MCP for IFTTT https://mcp.pipedream.com/app/ifttt

It’s more useful the other way :p

Re: MCP: An (Accidentally) Universal Plugin System

#243

Post by Art9681 »

klabb3 wrote: post #86
karaterobot wrote: post #51

Earlier quoted context omitted.

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

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?

Re: MCP: An (Accidentally) Universal Plugin System

#244

Post by klabb3 »

Art9681 wrote: post #243
klabb3 wrote: post #86

Earlier quoted context omitted.

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

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?

Re: MCP: An (Accidentally) Universal Plugin System

#245

Post by jetsnoc »

mh- wrote: post #50
sshine wrote: post #27

Earlier quoted context omitted.

Hype, certainly. 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…

Unfortunately, I think we're equally likely to see shortsighted lock-in attempts like this [0] one from Slack. 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…

I wasn’t aware of this, it’s extremely shortsighted. My employees’ chats are my company’s data, and I should be able to use them as I see fit. Restricting API access to our own data moves them quickly in to the 'too difficult to continue doing business with' category.

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

Re: MCP: An (Accidentally) Universal Plugin System

#246

Post by mh- »

jetsnoc wrote: post #245
mh- wrote: post #50

Earlier quoted context omitted.

Unfortunately, I think we're equally likely to see shortsighted lock-in attempts like this [0] one from Slack. 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…

I wasn’t aware of this, it’s extremely shortsighted. My employees’ chats are my company’s data, and I should be able to use them as I see fit. Restricting API access to our own data moves them quickly in to the 'too difficult to continue doing business with' category. 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…

Precisely the situation I'm in. I've fought off slack-to-teams migrations at multiple orgs for the same QoL reasons, but this will make that much (much) harder to justify.

Re: MCP: An (Accidentally) Universal Plugin System

#247

Post by baobun »

fragmede wrote: post #158
kasey_junk wrote: post #58

Earlier quoted context omitted.

Yes. Pieces of all of those things surround us now. And where we are wrt locking and interop is far beyond where we were when each of those fads happened. 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.

I know we're all just soaked by a wave of hype right now but I think MCP will go the way of other "but it works" tech, like zip files, RSS and shell scripts.

Remember when GraphQl was making REST obsolete? This rhymes.

Re: MCP: An (Accidentally) Universal Plugin System

#248

Post by zzo38computer »

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

Re: MCP: An (Accidentally) Universal Plugin System

#249

Post by mkagenius »

alangpierce wrote: post #200

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

Yes! Once the first integration is done. It will be static unless someone manually changes it.

Maybe the author is okay with that and just want new APIs (for his toaster).

Re: MCP: An (Accidentally) Universal Plugin System

#250

Post by mkagenius »

sureglymop wrote: post #190
mkagenius wrote: post #175

Earlier quoted context omitted.

My understanding is MCP = original APIs + 1 more API The additional API is /list-tools And all the clients consume the /list-tools first and then rest of the APIs depending on which tool they want to call.

Yes. But in order to do that you run the MCP server for that API locally. Is it really worth doing that just to have the additional /list-tools, when it is otherwise basically just a bridge/proxy?

Not quite sure I get what you mean by 'MCP server for that API locally'.

Locally you just need a consumer/client, isn't?

Post reply on HN