MCP: An (Accidentally) Universal Plugin System • Hacker News Board

Re: MCP: An (Accidentally) Universal Plugin System

#231

Post by bravesoul2 » Sun, Jun 29, 2025, 1:30 AM UTC

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.

     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.

Re: MCP: An (Accidentally) Universal Plugin System

#232

Post by recursivedoubts » Sun, Jun 29, 2025, 1:39 AM UTC

NomDePlum wrote: post #230

recursivedoubts wrote: post #224

Earlier quoted context omitted.

HTML is a hypermedia format, the most widely used, and it's designed mainly for human consumption. Machines parsing and using something is too broad an idea to engage with meaningfully: browsers parse HTML and do something with it: they present it to humans to select actions (i.e. hypermedia controls) to perform. Your understanding is incorrect, the links above will explain it. HATEOAS (and REST, which is a superset…

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?

Re: MCP: An (Accidentally) Universal Plugin System

#233

Post by anon7000 » Sun, Jun 29, 2025, 2:15 AM UTC

gavinray wrote: post #144

gdecaso wrote: post #141

Earlier quoted context omitted.

The main difference between MCP and REST is `list-tools`. REST APIs have 5 or 6 ways of doing that, including "read it from our docs site", HATEOAS, OAS running on an endpoint as part of the API. MCP has a single way of listing endpoints.

WSDL + XML API's have been around since 1998. OpenAPI, OData, gRPC, GraphQL I'm sure I'm missing a few...

In other words, there’s no commonly-used, agreed upon standard for creating APIs. The closest is REST-like APIs, which are really no more specific than “hit a URL and get some data back”.

So why are we all bitching about it? Programmatically communicating with an ML model is a new thing, and it makes sense it might need some new concepts. It’s basically just a wrapper with a couple of opinions. Who cares. It’s probably better to be more opinionated about what exactly you put into MCP, rather than just exposing your hundreds of existing endpoints.

Re: MCP: An (Accidentally) Universal Plugin System

#234

Post by anon7000 » Sun, Jun 29, 2025, 2:17 AM UTC

ramoz wrote: post #222

qsort wrote: post #20

Earlier quoted context omitted.

Regardless of how good a model gets, it can't do much if it doesn't have access to deterministic tools and information about the state of the world. And that's before you take into account security: you can't have a model running arbitrary requests against production, that's psychotic. I don't have a high opinion of MCP and the hype it's generating is ridicolous, but the problem it supposedly solves is real. If it ca…

> 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

Re: MCP: An (Accidentally) Universal Plugin System

#235

Post by bigiain » Sun, Jun 29, 2025, 2:22 AM UTC

stavros wrote: post #227

bigiain wrote: post #225

Earlier quoted context omitted.

I am pondering if I should do this. 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?

One of us doesn't understand MCP well enough, and it might very well be me, but how can MCP be used without an LLM? Most of the structure is in human language.

I will also freely admit to not understanding MCP much, but using it without an LLM was (at least to my reading) pretty much the main thesis of the linked article.

"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')

Re: MCP: An (Accidentally) Universal Plugin System

#236

Post by simulacra8 » Sun, Jun 29, 2025, 2:26 AM UTC

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

Re: MCP: An (Accidentally) Universal Plugin System

#237

Post by Jonovono » Sun, Jun 29, 2025, 2:37 AM UTC

jaredsohn wrote: post #109

Jonovono wrote: post #21

Earlier quoted context omitted.

MCP is not REST. In your comparison, its more that MCP is a protocol for discovering REST endpoints at runtime and letting users configure what REST endpoints should be used at runtime. Say i'm building a app and I want my users to be able to play spotify songs. Yea, i'll hit the spotify api. But now, say i've launched my app, and I want my users to be able to play a song from sonofm when they hit play. Alright, now…

Feels like segment.com but for calling APIs rather than adding libraries to the frontend.

Now make the segment for MCPs ;p

Re: MCP: An (Accidentally) Universal Plugin System

#238

Post by emporas » Sun, Jun 29, 2025, 2:37 AM UTC

Jonovono wrote: post #21

jadar wrote: post #4

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

MCP is not REST. In your comparison, its more that MCP is a protocol for discovering REST endpoints at runtime and letting users configure what REST endpoints should be used at runtime. Say i'm building a app and I want my users to be able to play spotify songs. Yea, i'll hit the spotify api. But now, say i've launched my app, and I want my users to be able to play a song from sonofm when they hit play. Alright, now…

>Alright, now I gotta open up the code and do some if statements hard code the sonofm api and ship a new version, show some update messages.

You will need to do that anyway. Easier discovery of the API doesn't say much.

The user might want a complicated functionality, which combines several API calls, and more code for filtering/sorting/searching of that information locally. If you let the LLM to write the code by itself, it might take 20 minutes and millions of wasted tokens of the LLM going back and forth in the code to implement the functionality. No user is going to find that acceptable.

Re: MCP: An (Accidentally) Universal Plugin System

#239

Post by Rury » Sun, Jun 29, 2025, 2:40 AM UTC

iambateman wrote: post #57

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?

Do you know WSDL? If you do, it's kind of the same concept behind consuming WSDL, just for AI applications...

Re: MCP: An (Accidentally) Universal Plugin System

#240

Post by jjfoooo4 » Sun, Jun 29, 2025, 2:45 AM UTC

anon7000 wrote: post #233

gavinray wrote: post #144

Earlier quoted context omitted.

WSDL + XML API's have been around since 1998. OpenAPI, OData, gRPC, GraphQL I'm sure I'm missing a few...

In other words, there’s no commonly-used, agreed upon standard for creating APIs. The closest is REST-like APIs, which are really no more specific than “hit a URL and get some data back”. So why are we all bitching about it? Programmatically communicating with an ML model is a new thing, and it makes sense it might need some new concepts. It’s basically just a wrapper with a couple of opinions. Who cares. It’s probab…

I don’t think the comments here are complaining, they are pointing out that what’s being claimed as being new is not actually new