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: An (Accidentally) Universal Plugin System
321–330 of 366 posts
Re: MCP: An (Accidentally) Universal Plugin System
#322Earlier 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.
Re: MCP: An (Accidentally) Universal Plugin System
#323Re: MCP: An (Accidentally) Universal Plugin System
#324Earlier 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.
Re: MCP: An (Accidentally) Universal Plugin System
#325Earlier 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…
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
#326Earlier 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.
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
#327This 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..
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
#328Earlier 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…
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
#329Earlier quoted context omitted.
Nobody remembers the semantic web anymore
Palantir remembers.. https://www.palantir.com/docs/foundry/ontology/overview
Re: MCP: An (Accidentally) Universal Plugin System
#330Earlier 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.
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.