Also, comments of the format "here's what an LLM said about this topic:" are best avoided. We don't want to normalise a style of discussing issues in which we generate an LLM output and make that the central conversation topic; we prefer original human thought here.
Not quite the same. The bash sdk can't be used to run arbitrary shell commands any more than to run arbitrary python programs.
https://github.com/dotemacs/emacs-mcp
I like the fact that it's just Bash
Not really in "pure bash". Also this needs to be labeled as a "toy".
Using an external tool like 'jq' especially written in C for parsing JSON, one can craft a exploitable JSON input to achieve code execution on the MCP server.
What could possibly go wrong? Maybe this CVE-2025-48060 [0] [1]?
We never should have abandoned REST. The whole point was for an interface to be self-describing; we wouldn't need MCP (or Swagger, or OpenAPI, etc) if we just stuck to REST instead of diverting down the JSON RPC route we've been on for 20 years.
And in what way is OpenAPI an abandonment of REST? It's an API documentation system that can be leveraged for generating REST server boilerplate code. If anything, it builds up the quality-of-life around REST.
There's a great chapter on this in Hypermedia Systems[1]. Talks about both this and HATEOAS(Hypermedia as the engine of application state).
1. https://hypermedia.systems/components-of-a-hypermedia-system...
That's anecdotal obviously, but almost every, if not every, API I use today is an RPC call returning JSON.
Edit: to be clear, the distinction between what REST was defined as and what we use today often doesn't really matter. We use JSON APIs today, it is what it is. This is a case where it really matters though, LLM companies are now trying to push an entirely new protocol that tries to do roughly what REST did in the first place.
The drum I'm currently beating is that local MCP is a ton of fun for techies like us - if you're on this website you can `npx ...` or install whatever you want with a modicum of common sense - but local MCP is going to be a dead end for mass adoption. If we want to build MCP servers that get used by everyday people (or on mobile or other locked down ecosystems) then remote MCP + OAuth is the only realistic way forward. I can't get my dad to open up a terminal window - anything over stdio or touching environment variables and API keys is a nonstarter.
rcleveng•8mo ago
skeeter2020•8mo ago
That's because it's not really doing anything new. MCP is a land-grab by one company, quickly supported by the rest as they desperately work to abstract and supplant with their own "protocols". Welcome to the era of thin veneers that add little but complexity over what we already had.
rcleveng•8mo ago
I looked at it more as there were N different ways of configuring tools to be called, so they created N+1 (https://xkcd.com/927/) but have had good success at getting alignment on it.
While not knowing the reasons that OpenAI supported it, I would imagine it was along the lines of: "This is not more bad than the others we have seen, may as well use it"
Since that time, thankfully many folks have jumped into looking at it and making it better. I just wish the spec was good and easy to follow (I read through it, and I'm still looking for the real spec)