[HN Gopher] Show HN: MCP Server SDK in Bash
___________________________________________________________________
Show HN: MCP Server SDK in Bash
Author : muthuishere
Score : 127 points
Date : 2025-05-30 04:25 UTC (18 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| rcleveng wrote:
| 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 wrote:
| >> 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.
| inercia wrote:
| Similar to https://github.com/inercia/MCPShell, but the MCPShell
| can sandbox the execution of the shell code for higher safety.
| samuel wrote:
| 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_ wrote:
| Did the AI help write this?
| mathgeek wrote:
| I love that "the AI" has become a modern day "the Google".
| esafak wrote:
| "I AI'd it."
| Too wrote:
| What does zero-overhead mean here?
| rcarmo wrote:
| 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 wrote:
| Interesting to see ppl caring about marshalling overhead when
| working with LLMs
| rcarmo wrote:
| 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...
| riobard wrote:
| This is neat but "zero runtime" is a misnomer. Bash _is_ runtime,
| not to mention external tools used in shell scripts like jq.
| dotemacs wrote:
| It works great with Emacs :)
|
| https://github.com/dotemacs/emacs-mcp
|
| I like the fact that it's just Bash
| cranberryturkey wrote:
| here's a node version of an MCP server:
| https://www.npmjs.com/package/@profullstack/mcp-server
| pjmlp wrote:
| Runtime is called POSIX userspace.
| baq wrote:
| Gross. I love it.
| rvz wrote:
| > 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]?
|
| [0] https://github.com/jqlang/jq/issues/3327
|
| [1] https://nvd.nist.gov/vuln/detail/CVE-2025-48060
| _heimdall wrote:
| 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.
| 0x445442 wrote:
| By REST you mean HATEOAS?
| wild_egg wrote:
| You can't have REST without it
| _heimdall wrote:
| That's one constraint of REST, yes.
| _verandaguy wrote:
| 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.
| mcdow wrote:
| 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).
|
| 1. https://hypermedia.systems/components-of-a-hypermedia-
| system...
| _heimdall wrote:
| 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.
| maxwellg wrote:
| 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 wrote:
| 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 wrote:
| 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.
| rcarmo wrote:
| I just rolled my own Python umcp library based on this, so thanks
| for the inspiration!
|
| https://github.com/rcarmo/umcp
___________________________________________________________________
(page generated 2025-05-30 23:01 UTC)