Ha! I love this. There's nothing like a proper Bash script to make me realize how terribly gross all of mine are.
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.
cruffle_duffle · 11h ago
The infrastructure around MCP has a long ways to go before ordinary people can use it. Don’t forget you also have to edit configuration files.
maxwellg · 10h ago
Oh absolutely - but the infrastructure required to support a "click link, get remote MCP URL added to config automatically" flow is _so_ much smaller than the infrastructure required for a "click link, download and install arbitrary software that may or may not depend on having existing tools installed" flow.
_heimdall · 17h ago
Very cool! The docs here are a great overview of how MCP works, and a reminder to me of an old lesson:
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.
_verandaguy · 14h ago
Wait, who's abandoned REST?
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.
_heimdall · 11h ago
I haven't seen a REST API in production for many years, maybe 15?
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.
mcdow · 12h ago
So the things we call "REST" in 2025 are not quite the same as the original specification of REST. One key aspect that has been abandoned is that sent data should be self-describing. That is, it shouldn't require any additional information to be useful. i.e. API documentation for JSON endpoints.
There's a great chapter on this in Hypermedia Systems[1]. Talks about both this and HATEOAS(Hypermedia as the engine of application state).
I have to say this is a very readable implementation to see how it all works in practice as well as a good reminder that it's a pretty simple universal tool interface.
skeeter2020 · 15h ago
>> a good reminder that it's a pretty simple universal tool interface.
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.
Raw protocol, really. No marshaling, no conversions, none of the overhead from type management you get with modern Python, none of the turtles-all-the-way-down dependencies of NodeJS equivalents. I like it, although I would probably port it back to “lightweight” Python in about half the size :)
tardyp · 19h ago
Interesting to see ppl caring about marshalling overhead when working with LLMs
rcarmo · 18h ago
Some of us still prize compute efficiency, especially those who have been using Python for a long time and are contemplating the new kinds of code patterns that have emerged from data science...
I don't think they are comparable. MCPShell is a go program to run shell scripts, while the other one allows to define MCP operations as bash functions.
Not quite the same. The bash sdk can't be used to run arbitrary shell commands any more than to run arbitrary python programs.
sam_lowry_ · 22h ago
Did the AI help write this?
mathgeek · 17h ago
I love that “the AI” has become a modern day “the Google”.
esafak · 13h ago
"I AI'd it."
baq · 18h ago
Gross. I love it.
rvz · 18h ago
> in pure 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]?
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.
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.
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.
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 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.
https://github.com/dotemacs/emacs-mcp
I like the fact that it's just Bash
https://github.com/rcarmo/umcp
Not quite the same. The bash sdk can't be used to run arbitrary shell commands any more than to run arbitrary python programs.
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]?
[0] https://github.com/jqlang/jq/issues/3327
[1] https://nvd.nist.gov/vuln/detail/CVE-2025-48060
No comments yet