Live data from Hacker News

MCP: An (Accidentally) Universal Plugin System

worksonmymachine.substack.com

321–330 of 366 posts

Re: MCP: An (Accidentally) Universal Plugin System

#321

This isn't a snide comment, I am legitimately asking. I don't understand the difference between MCP and REST. I know there are differences because I've used it a little. I mean, like, on an existential level. Why isn't it just REST? What parts do MCP give us that REST doesn't?

mcp forces a standard documentation, whereas documentation is optional for rest

Re: MCP: An (Accidentally) Universal Plugin System

#322
post #218

Earlier quoted context omitted.

Sounds like programming! What happened to low code/no code? I AM old, retired in fact. IT has more "middleware" than the library of congress and mainframes still exist. But I will dig around, because I'm still curious. Carry on. LOL

Erm, hey Mac, he’s quoting “TRON” -and getting downvoted by peeps who don’t remember or are from alien cultures that don’t incorporate it.

Maybe I'm just too old, myself :)

Re: MCP: An (Accidentally) Universal Plugin System

#324
post #319

Earlier quoted context omitted.

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

Thanks for building this, but also ridiculous that you had to do it. I miss irc even though slack is objectively better.

Hard disagree, IRC is still the best chat application out there.

Re: MCP: An (Accidentally) Universal Plugin System

#325

Earlier quoted context omitted.

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.

MCP itself doesn't require the use of the LLM. There are other concepts, but for this use, Tools are key. A Tool is an operation, like a search. Have a look at the Filesystem example MCP server - https://github.com/modelcontextprotocol/servers/blob/main/sr... . It has a collection of Tools - read_file, read_multiple_files, write_file, etc. The LLM uses MCP to learn what tools the server makes available; the LLM decid…

Yeah MCP isn't really doing a whole lot. You can give an LLM a generic HTTP extension. Then list a series of GET/POST/PUT and ask it to form the calls and parse the response. The problem is its not really ideal as the calls aren't natural language and its common for it to misguess the next token and mess up things like the route, body, headers, with a hallucination. So people started shortening these calls to simple things like read_file, etc. Prior to MCP there was a ton of playgrounds doing this with simple Playwright functions.

The thing that surprises me is with MCP we have shirked all of the existing tools around OpenAPI specs, OIDC, etc. We could have created a system where all 'services' expose a mcp.slack.com/definition endpoint or something that spit back a list of shortcut terms like send_message and a translation function that composes it into the correct HTTP API (what most MCP servers do). For security we could have had the LLM establish its identity via all our existing systems like OIDC that combine authentication and authorization.

In the system above you would not "install an mcp package" as in a code repo or server. Instead you would allow your LLM to access slack, it would then prompt you to login via OIDC and establish your identity and access level. Then it would grab the OpenAPI spec (machine readable) and the LLM focused shortcuts 'send_message', 'read_message', etc. LLM composes 'send_message Hello World' -> translates to HTTP POST slack.com/message or whatever and bob's your uncle.

If you wanted to do fancy stuff with local systems then you could still build your own server the same way we have all built HTTP servers for decades and just expose the mcp.whatever.com subdomain for discovery. Then skip OIDC or allow ALL or something to simplify if you want.

Re: MCP: An (Accidentally) Universal Plugin System

#326

Earlier quoted context omitted.

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.

Right, so that means that the primary novel aspect of REST (according to the coiner of that term, Roy Fielding), the uniform interface, is largely wasted. Effectively you get a level of indirection on top of hard-coded API response endpoints. Maybe better, but I don't think by much and a lot of work for the payoff.

To take advantage of the uniform interface you need to have a consumer with agency who can respond to new and novel interactions as presented in the form of hypermedia controls. The links above will explain more in depth, the section on REST in our book is a good overview:

https://hypermedia.systems/components-of-a-hypermedia-system...

Re: MCP: An (Accidentally) Universal Plugin System

#327
post #197

This isn't a snide comment, I am legitimately asking. I don't understand the difference between MCP and REST. I know there are differences because I've used it a little. I mean, like, on an existential level. Why isn't it just REST? What parts do MCP give us that REST doesn't?

I cannot really answer, but it seems you can just wrap mcp in a rest wrapper, as thqt is how open web ui seems to integrate mcp into its tooling..

Anthropic's example of creating an MCP server is just wrapping MCP around a REST weather forecasting service.

Maybe it's just that agentic LLMs have created a lot of interest in being interoperable, whereas efforts like Open API just didn't have any carrot to warrant the stick other than "wouldn't it be nice".

Re: MCP: An (Accidentally) Universal Plugin System

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

I wasn’t aware of this, it’s extremely shortsighted. My employees’ chats are my company’s data, and I should be able to use them as I see fit. Restricting API access to our own data moves them quickly in to the 'too difficult to continue doing business with' category. The reality is that Slack isn’t that sticky. The only reason I fended off the other business units who've demanded Microsoft Teams through the years is…

> I wasn’t aware of this, it’s extremely shortsighted. My employees’ chats are my company’s data, and I should be able to use them as I see fit.

True, and if you're the only one sitting on the data and using it, then what you say is true.

The moment you use another platform, entering agreements of terms of service and more, it stops being "your and/or your company's data" though, and Slack will do whatever they deem fit with it, including preventing you from getting all of the data, because then it gets easier for you to leave.

Sucks, yeah, but it is the situation we're in, until lawmakers in your country catch up. Luckily, other jurisdictions are already better for things like this.

Re: MCP: An (Accidentally) Universal Plugin System

#329
post #69

Earlier quoted context omitted.

Nobody remembers the semantic web anymore

Palantir remembers.. https://www.palantir.com/docs/foundry/ontology/overview

That isn’t the same at all. Ontologies in Foundry are not defined with triplets like they are in the semantic web. Ontologies in Palantir are just a set of object types with properties, and objects of each type.

Re: MCP: An (Accidentally) Universal Plugin System

#330
post #309

Earlier quoted context omitted.

We migrated from Slack to Teams and while it does work, it’s also not very good (UI/UX wise). We also did try out Rocket.Chat and Mattermost and out of all of those Mattermost was the closest to Slack and the most familiar to us.

I’d go for Discord if it had a business version without all the gaming stuff. The dedicated voice/video channels are great for ad-hoc conversations when remote and a lot better than Slack’s huddles. They’re like dedicated remote meeting rooms except you’re not limited by office space.

> I’d go for Discord if it had a business version without all the gaming stuff.

Granted, my Discord usage been relatively limited, but what "gaming stuff"? In the servers unrelated to gaming I don't think I see anything gaming related, but maybe I'm missing something obvious.

Post reply on HN