← Back to context

Comment by robot-wrangler

5 days ago

Well if your language of choice didn't have any good library support for HTTP, the web version of hello world would be hard too, but it would not say much about the protocol.

Even with these constraints the core MCP design is actually pretty good. First, use stdio transport, and now your language only needs to speak JSON [1]. Then, forget about building proxies and routers and web stuff, and offload that to mcpjungle [2] or similar to front your stdio work.

If that still doesn't work, I think I would probably wrap the foreign language with subprocs and retreat towards python's FastMCP (or whatever the well-supported and fast-moving stuff is in another language). Ugly but practical if you really must use a language with no good MCP support. If really none of that works I guess one is on the hook to support a changing MCP spec with a custom implementation in that language.. but isn't there maybe an argument now that MCP is complex because someone insisted on it being complex?

[1]: https://modelcontextprotocol.io/specification/2025-06-18/bas... [2]: https://github.com/mcpjungle/MCPJungle

My use case was adding the ability to charge for MCP calls to remote MCP providers. This involves a “simple on paper” wrap, proxy, insert tools on the proxy/charging server side. A number of the paradigms you mention just aren’t great, e.g. stdio over http doesn’t work (and I’ll reference you to the lengthy GitHub issues conversations at the MCP GitHub about how they want to support it when the server is not local), and in fact MCP over TCP is just literally months old. Anyway, like I said, if you’re on a golden path that tracks the monorepo delivered by the spec folks, I agree with you, it works pretty well.

For reference, I think writing an MCP proxy layer in (lang of choice) is significantly harder than writing something to respond to GET / over http, both in complexity of what clients need out of a server (web clients are hardened to deal with all kinds of bad behavior), and in the amount of stuff you actually need to write, and also in the lack of documentation.