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

121–130 of 366 posts

Re: MCP: An (Accidentally) Universal Plugin System

#121

Post by mort96 »

layer8 wrote: post #62
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…

HATEOAS was supposed to be that. https://en.wikipedia.org/wiki/HATEOAS

Wait was it? HATEOAS is all about hypermedia, which means there must be a human in the loop being presented the rendered hypermedia. MCP seems like it's meant to be for machinemachine communication, not humanmachine

Re: MCP: An (Accidentally) Universal Plugin System

#122

Post by billmcneale »

vinkelhake wrote: post #52

While reading this, the old ARexx (Amiga Rexx) popped into my head. It was a scripting language that in itself wasn't very noteworthy. However, it also made it easy for applications to expose functionality through an ARexx port. And again, offering up an API itself isn't noteworthy either. But it shipped by default in the system and if an application wanted to open itself up for scripting, ARexx was the natural choic…

Microsoft introduced this in Windows in 1993, it's called COM and is still in (heavy) use today.

It basically powers all inter communication in Windows.

Re: MCP: An (Accidentally) Universal Plugin System

#123

Post by chopete3 »

The real accident is that the prompts became a programming language. I don't think the ML Engineers set out to create a general purpose programming language.

A2A (agent 2 agent) mechanism is an another accidental discovery for the interoperability across agent boundaries

Re: MCP: An (Accidentally) Universal Plugin System

#124

Post by Animats »

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…

> Want spell check? MCP server.

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

Re: MCP: An (Accidentally) Universal Plugin System

#125

Post by talos_ »

mellosouls wrote: post #82
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 AI Agent wave made interoperability hype, and vendor lock-in old-fashioned 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 u…

The VSCode extension Continue provides similar capabilities and gives you full access to your interaction traces (local database and JSON traces)

Re: MCP: An (Accidentally) Universal Plugin System

#126

Post by ashwinsundar »

jampa wrote: post #10

I don't want to sound like a skeptic, but I see way more people talking about how awesome MCP is rather than people building cool things with it. Reminds me of blockchain hype. MCP seems like a more "in-between" step until the AI models get better. I imagine in 2 years, instead of using an MCP, we will point to the tool's documentation or OpenAPI, and the AI can ingest the whole context without the middle layer.

I had a use case - I wanted to know what the congresspeople from my state have done this week. This information is surprisingly hard to just get from the news. I learned about MCP a few months ago and thought that it might be a cool way to interact with the congress.gov API.

I made this MCP server so that you could chat with real-time data coming from the API - https://github.com/AshwinSundar/congress_gov_mcp. I’ve actually started using it more to find out, well, what the US Congress is actually up to!

Re: MCP: An (Accidentally) Universal Plugin System

#127

Post by layer8 »

mort96 wrote: post #121
layer8 wrote: post #62

Earlier quoted context omitted.

HATEOAS was supposed to be that. https://en.wikipedia.org/wiki/HATEOAS

Wait was it? HATEOAS is all about hypermedia, which means there must be a human in the loop being presented the rendered hypermedia. MCP seems like it's meant to be for machine machine communication, not human machine

I agree that HATEOAS never made sense without a human in the loop, although I also have never seen it be described as such. IMO that’s an important reason why it never gained useful traction.

There is a confused history where Roy Fielding described REST, then people applied some of that to JSON HTTP APIs, designating those as REST APIs, then Roy Fielding said “no you have to do HATEOAS to achieve what I meant by REST”, then some people tried to make their REST APIs conform to HATEOAS, all the while that change was of no use to REST clients.

But now with AI it actually can make sense, because the AI is able to dynamically interpret the hypermedia content similar to a human.

Re: MCP: An (Accidentally) Universal Plugin System

#128

Post by notatoad »

Animats wrote: post #124
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…

> Want spell check? MCP server. > 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?

the whole point of the article is that it doesn't need to be an LLM, MCP is just a standard way to expose tools to things that use tools. LLMs can use tools, but so can humans.

Re: MCP: An (Accidentally) Universal Plugin System

#129

Post by conradev »

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…

AI agents didn't only make adversarial interoperability hype, they've also made it inevitable! From here all the way until they're probing hardware to port Linux and write drivers.

Re: MCP: An (Accidentally) Universal Plugin System

#130

Post by talos_ »

Spivak wrote: post #73
xg15 wrote: post #39

Earlier quoted context omitted.

Is it "self-described" in the sense I can get a list of endpoints or methods, with a human- (or LLM-) readable description for each - or does it supply actual schemata that I could also use with non-AI clients? (Even if only the former, it would of course be a huge step forward, as I could have the LLM generate schemata. Also, at least, everyone is standardizing on a base protocol now, and a way to pass command names…

For each tool you get the human description as well as a JSON schema for the parameters needed to call the function.

You're getting an arbirary string back though...
Post reply on HN