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

291–300 of 366 posts

Re: MCP: An (Accidentally) Universal Plugin System

#291

Post by gillesjacobs »

troupo wrote: post #274
freeone3000 wrote: post #147

Earlier quoted context omitted.

The issue holding us back was never that we had to write a frontend — it was the data locked behind proprietary databases and interfaces. Gated behind API keys and bot checks and captchas and scraper protection. And now we can have an MCP integrator for IFTTT and have back the web we were promised, at least for a while.

So... How do MCPs magically unlock data behind proprietary databases and interfaces?

It doesn't do it magically. The "tools" an LLM agent calls to create responses are typically REST APIs for these services.

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.

Re: MCP: An (Accidentally) Universal Plugin System

#292

Post by Valodim »

brabel wrote: post #278
SoftTalker wrote: post #152

Earlier quoted context omitted.

Sounds sort of like an innovator's dilemma response. New technology appears and the response is gatekeeping and building walls rather than adaptation.

Slack was never an innovator. By the time they showed up there were lots of chats apps. They just managed to go beyond the others by basically embedding a browser engine into their app at a time most thought of that as heresy, I mean a chat app that requires 1Gb to run was a laughable proposition to us, techies. But here we are… MS Teams is even heavier, but users seem to care nothing about that anyway.

They were never an innovator, they just did this thing nobody else did, that some years later became the norm?

Re: MCP: An (Accidentally) Universal Plugin System

#293

Post by [deleted] »

ggambetta wrote: post #269
alexpotato wrote: post #202

Earlier quoted context omitted.

Reminds me of the days of Winsock. 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. https://en.wikipedia.org/wiki/Winsock

Trumpet Winsock! Brings back memories :)

[deleted]

Re: MCP: An (Accidentally) Universal Plugin System

#294

Post by pyman »

ggambetta wrote: post #269
alexpotato wrote: post #202

Earlier quoted context omitted.

Reminds me of the days of Winsock. 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. https://en.wikipedia.org/wiki/Winsock

Trumpet Winsock! Brings back memories :)

I think we're seeing a wave of hype marketing on YouTube, Twitter and LinkedIn, where people with big followings create posts or videos full with buzzwords (MCP, vibe coding, AI, models, agentic) with the sole purpose of promoting a product like Cursor, Claude Code or Gemini Code, or get people to use Anthropic's MCP instead of Google's A2A.

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.

Re: MCP: An (Accidentally) Universal Plugin System

#295

Post by sshine »

ebiester wrote: post #59
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…

It's going to take more people willing to move away from slack for those purposes. 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.

The argument used to be “Let’s move FOSS conversation out of {Slack, Discord} because they prevent conversations from being globally searchable, and they force individuals into subscription to access history backlog.”

Getting indexed by AI crawlers appears to be the new equivalent to getting indexed by search engines.

Re: MCP: An (Accidentally) Universal Plugin System

#296

Post by thiht »

edgolub wrote: post #279
thiht wrote: post #275

Earlier quoted context omitted.

Yes I understand that, but how do I write these endpoints myself without using magic @mcp annotations? After like an hour of searching I finally found the Lifecycle page: https://modelcontextprotocol.io/specification/2025-06-18/bas... and I think it contains the answers I’m looking for. But I feel this should be roughly explained in the first introduction. Agree that most of the pages feel LLM generated, and borderli…

The reason why they do not expose the underlying server schema, is because you aren't supposed to write your own MCP server from zero, in the same way you aren't supposed to write your own GraphQL Server from zero. Yes, technically you could, but you are "supposed" to just use a library that builds the actual endpoints based on the schema for the version of MCP you are using. And only worry about building your tools,…

I can get behind that, but if you’re not supposed to write your MCP server yourself, it makes even more sense to explain how it works so people understand why

Re: MCP: An (Accidentally) Universal Plugin System

#297

Post by NomDePlum »

renerick wrote: post #252
NomDePlum wrote: post #230

Earlier quoted context omitted.

I've programmed machines to use those links so I'm pretty certain machines can use it. I've never heard of the HTML variation but so will have a look at those links.

> I've programmed machines to use those links so I'm pretty certain machines can use it I'm curious to learn how it worked. The way I see it, the key word here is "programmed". Sure, you read the links from responses and eliminated the need to hardcode API routes in the system, but what would happen if a new link is created or old link is unexpectedly removed? Unless an app somehow presents to the user all available…

Yes, most of your observations about limitations are true. That doesn't mean it's not a useful technique.

This is a reasonable summary of how I understand it: https://martinfowler.com/articles/richardsonMaturityModel.ht...

This aligns with how I've seen it used. It helps identify forward actions, many of which will be standard to the protocol or to the domain. These can be programmed for and traversed, called or aggregated data presented using general or specific logic.

So New actions can be catered for but Novel actions cannot, custom logic would require to be added. Which then becomes part of the domain and the machine can now potentially handle it.

Hope that helps illustrate how it can be used programmatically.

Re: MCP: An (Accidentally) Universal Plugin System

#298

Post by NomDePlum »

recursivedoubts wrote: post #232
NomDePlum wrote: post #230

Earlier quoted context omitted.

I've programmed machines to use those links so I'm pretty certain machines can use it. I've never heard of the HTML variation but so will have a look at those links.

how did the machines you programmed react to new and novel links/actions in the response?

New are fine, Novel need catered for. I have left a fuller explanation to a sibling comment.

Re: MCP: An (Accidentally) Universal Plugin System

#299

Post by secos »

Valodim wrote: post #292
brabel wrote: post #278

Earlier quoted context omitted.

Slack was never an innovator. By the time they showed up there were lots of chats apps. They just managed to go beyond the others by basically embedding a browser engine into their app at a time most thought of that as heresy, I mean a chat app that requires 1Gb to run was a laughable proposition to us, techies. But here we are… MS Teams is even heavier, but users seem to care nothing about that anyway.

They were never an innovator, they just did this thing nobody else did, that some years later became the norm?

Blitzscaled? Yep.

Re: MCP: An (Accidentally) Universal Plugin System

#300

Post by secos »

visarga wrote: post #89
phh wrote: post #22

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

The main benefit is not that it made interoperability fashionable, or that it make things easy to interconnect. It is the LLM itself, if it knows how to wield tools. It's like you build a backend and the front-end is not your job anymore, AI does it. 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 anythi…

To me it feels like an awkward API that creates opportunities to work the limitations of a normal API... which to me is not a great thing. Potentially useful, sure, but not great.
Post reply on HN