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

251–260 of 366 posts

Re: MCP: An (Accidentally) Universal Plugin System

#251

Post by zackify »

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…

It is new and exciting if you just learned to vibe code, and you don’t even know what a rest api is

Re: MCP: An (Accidentally) Universal Plugin System

#252

Post by renerick »

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.

> 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 actions generated from those links, it would have to be modified every time to take advantage of newly added links. It would also need a rigorous existence checking for every used link, otherwise the system would break if a link is suddenly removed. You could argue that it would not happen, but now it's just regular old API coupling with backward compatibility concerns.

Building on my previous example of hn comments, if hn decides to add another action, for example "preview", the browser would present it to the user just fine, and the user would be able to immediately use it. They could also remove the "reply" button, and again, nothing would break. That would render the form somewhat useless of course, but that's the product question at this point

Re: MCP: An (Accidentally) Universal Plugin System

#253

Post by navigate8310 »

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…

Can't you just build a simple REST that takes this abstraction of plugging in different song providers away?

Re: MCP: An (Accidentally) Universal Plugin System

#254

Post by kimjune01 »

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…

If you are interested in scraping slack for personal use, I made a local-only slack scraper mcp: https://github.com/kimjune01/slunk-mcp

Re: MCP: An (Accidentally) Universal Plugin System

#255

Post by metalrain »

MCP works for small, well defined actions (like examples in the article), but enterprise APIs can have hundreds/thousands of endpoints/schemas for different concepts and variations of operations.

For example how would you MCP Google Ads rpc API https://developers.google.com/google-ads/api/reference/rpc/v... so that LLM and user will understand that? Seems like we can't escape complexity.

Re: MCP: An (Accidentally) Universal Plugin System

#256

Post by data-ottawa »

rikafurude21 wrote: post #26
quotemstr wrote: post #8

It's articles like this that tell you we're close to peak hype. There's nothing revolutionary about a text encoding plus a schema. SOAP could do this 20 years ago.

This reminded me of that HN comment on the Dropbox announcement post where the user says that theres nothing new about it since FTP and USB-sticks exist. Also, anyone who ever had the misfortune of using SOAP know how horrendeous it is. Truth is, sometimes the "new thing" does it better and wins out. Applications have standardized APIs now because of AI hype. This is a step in the right direction

Being able to plug MCPs into my desktop Claude app has been awesome. I gave it a K/V store and access to my project folder and it uses the tools very well with minimal guidance.

Today there's no way I can talk an average person into getting MCP working without them having to modify some config files hidden away somewhere.

I would bet big money that as soon as Claude and ChatGPT add 1 click "app store" experiences everyone will be using them in a week.

It is not easy to "just" use an API as a human, plus a lot of APIs force you to deal with tokens and storing+executing code. In some cases it's easier for the LLM to simply fetch or curl basic APIs directly than waste context tokens on the overhead of an MCP tool call (e.g. all these weather tool examples), but with MCP consistency is much better, so depending on the use case MCP vs API both have advantages.

Since my comment is already pretty long: LLM+RSS+Fetch is a killer combination for me, and it's almost all off the shelf these days. Once I add an RSS merge tool I think it will be an excellent way to consume content.

Re: MCP: An (Accidentally) Universal Plugin System

#257

Post by debugnik »

doug_durham wrote: post #170
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...

Where is "list-tools" in any of those low level protocols?

All of them already provide an IDL with text descriptions and a way to query a server's current interface, what else do we need? Just force those two optional features to be required for LLM tool calls and done.

Is there anything stopping generic MCP servers for bridging those protocols as-is? If not, we might as well keep using them.

Re: MCP: An (Accidentally) Universal Plugin System

#258

Post by Too »

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…

That only works if you let the LLM do the interpretation of the MCP descriptions, in the case of TFA the idea was to use MCP without LLM, which is essentially same as any old API.

Re: MCP: An (Accidentally) Universal Plugin System

#259

Post by neoden »

newtwilly wrote: post #115
neoden wrote: post #67

So much scepticism in the comments. I spent last week implementing an MCP server and I must say that "well-designed" is probably an overstatement. One of the principles behind MCP is that "an MCP server should be very easy to implement". I don't know, maybe it's a skill issue but it's not that easy at all. But what is important imo, is that so many eyes are looking in one direction right now. That means, it has good…

It's pretty easy if you just use the MCP Python library. You just put an annotation on a function and there's your tool. I was able to do it and it works great without me knowing anything about MCP. Maybe it's a different story if you actually need to know the protocol and implement more for yourself

Yes, I am using their Python SDK. But you can't just add MCP to your existing API server if it's not ready to async Python. Probably, you would need to deploy it as a separate server and make server-to-server to your API. Making authentication work with your corporate IAM provider is a path of trial and error — not all MCP hosts implement it the same way so you need to compare behaviours of multiple apps to decide if it's your setup that fails or bugs in VS Code or something like that. I haven't even started to think about the ability of a server to message back to the client to communicate with LLM, AFAIK modern clients don't support such a scenario yet, at least don't support it well.

So yes, adding a tool is trivial, adding an MCP server to your existing application might require some non-trivial work of probably unnecessary complexity.

Re: MCP: An (Accidentally) Universal Plugin System

#260

Post by baq »

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.

You write a script which pretends to be an LLM to get the data you want reliably.

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.

Post reply on HN