Live data from Hacker News

MCP: An (Accidentally) Universal Plugin System

worksonmymachine.substack.com

171–180 of 366 posts

Re: MCP: An (Accidentally) Universal Plugin System

#171
post #156

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.

> The main difference between MCP and REST is `list-tools`. > REST APIs have 5 or 6 ways of doing that You think nobody's ever going to publish a slight different standard to Anthropic's MCP that is also primarily intended for LLMs?

Why would they? I'm sure the "Enterprise" folks are putting together some working group to develop ANSI-xyzzy standard for Enterprise operability which will never see the light of day.

Re: MCP: An (Accidentally) Universal Plugin System

#172
post #86

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

I think battlestar Galactica must be quoting one of the Eddas. I've only read if it from Borges in Spanish, but Conner the same meaning: "Estas cosas han pasado. Estas cosas también pasarán."

Re: MCP: An (Accidentally) Universal Plugin System

#173
post #70

Earlier quoted context omitted.

XML actually works better with LLMs than JSON.

Why?

Presumably because XML tags give better context. You have closing tags, and each array element has its own tags. The tag syntax is different from the value syntax, whereas in JSON both labels and string values use the same syntax. JSON strings are delimited by the same character ("), whereas XML uses two different characters (>…<). Non-string values in JSON have more variations in their delimitation than values in XML.

Re: MCP: An (Accidentally) Universal Plugin System

#174
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…

One major difference is that MCP has discovery built into the protocol. There’s nothing in REST that informs clients what the API can do, what resources are available, etc.

Re: MCP: An (Accidentally) Universal Plugin System

#175

I've thought of this as well but in reality, aren't MCP servers mostly just clients for pre existing APIs? For example, the Kagi MCP server interacts with the Kagi API. Wouldn't you have a better experience just using that API directly then? On another note, as the number of python interpreters running on your system increases with the number of MCP servers, does anyone think there will be "hosted" offerings that jus…

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.

Re: MCP: An (Accidentally) Universal Plugin System

#176

Earlier quoted context omitted.

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.

So the whole point of the article is that an API is an API and anything can call an API?

There is a long tail of applications that are not currently scriptable or have a public API. The kind that every so often make you think "if only I could automate this instead of clicking through this exact same dialog 25 times"

Before, "add a public API to this comic reader/music player/home accounting software/CD archive manager/etc." would be a niche feature to benefit 1% of users. Now more people will expect to hook up their AI assistant of choice, so the feature can be prioritized.

The early MCP implementations will be for things that already have an API, which by itself is underwhelming.

You would think Apple would have a leg up here with AppleScript already being a sanctioned way to add scriptable actions across the whole of macOS, but as far as I can tell they don't hook it up to Siri or Apple Intelligence in any way.

Re: MCP: An (Accidentally) Universal Plugin System

#177

Earlier quoted context omitted.

> we will point to the tool's documentation or OpenAPI You can already do this as long as your client has access to a HTTP MCP. You can give the current generation of models an openAPI spec and it will know exactly what to do with it.

you don't even need MCP for that. just access to hosted swagger file.

That's what I mean. Give an LLM the swagger file, and it can make those calls itself given the ability to make an HTTP request (which is what the MCP is for)

Re: MCP: An (Accidentally) Universal Plugin System

#178

Earlier quoted context omitted.

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

Part of the reason AI agents and MCP work is because AI can programmatically at runtime determine what plug-ins to use. Without the AI part, how does the host app know when to call a MCP server function?

Re: MCP: An (Accidentally) Universal Plugin System

#180

Earlier quoted context omitted.

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.

So the whole point of the article is that an API is an API and anything can call an API?

I see the point as "let's not overcomplicate the API with complex schemas and such. Lets not use GraphQL for everything. Just create a simple API and call it to extend stuff. Am I wrong?
Post reply on HN