6 ms·
In the same way that crypto folks speedran "why we have finance regulations and standards", LLM folks are now speedrunning "how to build software paradigms". T
by hirsin 1y ago
In the same way that crypto folks speedran "why we have finance regulations and standards", LLM folks are now speedrunning "how to build software paradigms".
The concept they're trying to accomplish (expose possibly remote functions to a caller in an interrogable manner) has plenty of existing examples in DLLs, gRPC, SOAP, IDL, dCOM, etc, but they don't seem to have learned from any of them, let alone be aware that they exist.
Give it more than a couple months though and I think we'll see it mature some more. We just got their auth patterns to use existing rails and concepts, just have to eat the rest of the camel.
- MuffinFlavored 1y agoIsn't MPC based on JSON-RPC?
- hirsin 1y agoIndeed! But seemingly only for the actual object representation - it's a start, and I wonder if JSON is uniquely suited to LLMs because it's so text-first.
- immibis 1y agoI understand those with experience have found that XML works better because it's more redundant.
- wisemang 1y agoIs it the redundancy? Or is it because markup is a more natural way to annotate language, which obviously is what LLMs are all about? Genuinely curious, I don’t know the answer. But intuitively JSON is nice for easy to read payloads for transport but to be able to provide rich context around specific parts of text seems right up XML’s alley?
- giantrobot 1y agoThe lack of inline context is a failing of JSON and a very useful feature of XML. Two simple but useful examples would be inline markup to define a series of numbers as a date or telephone number or a particular phrase tagged as being a different language from the main document. Inline semantic tags would let LLMs better understand the context of those tokens. JSON can't really do that while it's a native aspect of XML.
- solidasparagus 1y agoOr is is because most text in existence is XML - or more specifically HTML.
- sitkack 1y agoHey, at least they didn't use yaml-rpc.
- _raz 1y agotoml-rpc anyone? :)
- neuroelectron 1y agoI think JSON is preferred because it adds more complexity.
- sroussey 1y agoI think it works because json is verbose and reinforces what everything is in each record.
- visarga 1y agoFrom this point of view XML offers all that and named brackets.
- sroussey 1y agoTrue. Even better with inline attributes.
- DonHopkins 1y agoI Wanna Be <![CDATA[ Sung to the tune of “I Wanna Be Sedated”, with apologies to The Ramones. ]]> https://donhopkins.medium.com/i-wanna-be-cdata-3406e14d4f21 https://donhopkins.medium.com/i-wanna-be-cdata-3406e14d4f21
- _raz 1y agoYes, the protocol seems fine to me in and of itself. It's the transport portion that seems to be a dumpster fire on the HTTP side of things.
- foobarian 1y agoMust have used GraphQL as a role model no doubt
- LegNeato 1y agoGraphQL is transport agnostic
- koakuma-chan 1y agoThis article feels like an old timer who knows WebSockets just doesn't want to learn what SSE is. I support the decision to ditch WebSockets because WebSockets would only add extra bloat and complexity to your server, whereas SSE is just HTTP. I don't understand though why have "stdio" transport if you could just run an HTTP server locally.
- fendy3002 1y agoHTTP call may be blocked by firewalls even internally, and it's overkill to force stdio apps to expose http endpoints for this case only. As in, how MCP client can access `git` command without stdio? You can run a wrapper server for that or use stdio instead
- koakuma-chan 1y ago> As in, how MCP client can access `git` command without stdio? MCP clients don't access any commands. MCP clients access tools that MCP servers expose.
- fullstackchris 1y agoHere's a custom MCP tool I use to run commands and parse stdout / stderr all the time: try { const execPromise = promisify(exec); const { stdout, stderr } = await execPromise(command); if (stderr) { return { content: [{ type: "text", text: `Error: ${stderr}` }], isError: true }; } return { content: [{ type: "text", text: stdout }], isError: false }; } catch (error: any) { return { content: [{ type: "text", text: `Error executing command: ${error.message}` }], isError: true }; } Yeah, if you want to be super technical, it's Node that does the actual command running, but in my opinion, that's as good as saying the MCP client is...
- matchagaucho 1y agoAlso missing in these strict, declarative protocols is a reliance on latent space, and the semantic strengths of LLMs. Is it sufficient to put a agents.json file in the root of the /.well-known web folder and let agents just "figure it out" through semantic dialogue? This forces the default use of HTTP as Agent stdio.
- snthpy 1y agoBravo. Agree with both of your examples.
- ethbr1 1y ago> Give it more than a couple months though and I think we'll see it mature some more. Or like the early Python ecosystem, mistakes will become ossified at the bottom layers of the stack, as people rapidly build higher level tools that depend on them. Except unlike early Python, the AI ecosystem community has no excuse, BECAUSE THERE ARE ALREADY HISTORICAL EXAMPLES OF THE EXACT MISTAKES THEY'RE MAKING.
- volemo 1y agoCould you throw on a couple of examples of calcified early mistakes of Python? GIL is/was one, I presume?
- Doxin 1y agoPossibly packaging too? though lately that has improved to the point where I'd not really consider it ossified at all.
- fullstackchris 1y ago> early mistakes of Python? Python.
- achierius 1y agoCPython in particular exposes so much detail about its internal implementation that other implementations essentially have to choose between compatibility and performance. Contrast this with, say, JavaScript, which is implemented according to a language standard and which, despite the many issues with the language, is still implemented by three distinct groups, all reasonably performant, yet all by and large compatible.
- Timwi 1y agoStatic functions (len, map/filter,...) that should have been methods on objects.
- azeirah 1y agoThis one frustrates me so, so much.
- wunderwuzzi23 1y agoYour comment reminds me that when I first wrote about MCP it reminded me of COM/DCOM and how this was a bit of a nightmare, and we ended up with the infamous "DLL Hell"... Let's see how MCP will go. https://embracethered.com/blog/posts/2025/model-context-protocol-security-risks-and-exploits/ https://embracethered.com/blog/posts/2025/model-context-prot...
- baxtr 1y agoTo this date I have not found a good explanation what an MCP is. What is it in old dev language?
- _raz 1y agoA RPC standard that plays nicely with LLMs?
- kaoD 1y agoIn a nutshell: RPC with builtin discoverability for LLMs.
- jimmySixDOF 1y agoold dev language is deterministic, llm in the loop now so the language is stochastic.
- jgalt212 1y agoit is amazing we used to prize determinism, but now it's like determinism is slowing me down. I mean how do you even write test cases for LLM agents. Do you have another LLM judge the results as close enough, or not close enough?
- jdlshore 1y agoYes, and you have to do it in a loop on every request. Not joking. It’s called “LLM as judge.”
- collingreen 1y agoWhat an amazing business to convince people to use. Making people pay to use LLMs to supervise the LLMs they pay for in order to get decent results is diabolically genius. At the risk of offending some folks it feels like the genius of the Mormon church making its "customers" pay the church AND work for it for free AND market it for free in person AND shame anyone who wants to leave. Why have cost centers if you don't have to! It's a business model I wasn't smart or audacious enough to even come up with.
- northern-lights 1y agoalso called Vibe Designing.
- TheOtherHobbes 1y agoIt's a classic Worse is Better situation. Most users don't care about the implementation. They care about the way that MCP makes it easier to Do Cool Stuff by gluing little boxes of code together with minimal effort. So this will run ahead because it catches developer imagination and lowers cost of entry. The implementation could certainly be improved. I'm not convinced websockets are a better option because they're notorious for firewall issues, which can be showstoppers for this kind of work. If the docs are improved there's no reason a custom implementation in Go or Arm assembler or whatever else takes your fancy shouldn't be possible. Don't forget you can ask an LLM to do this for you. God only knows what you'll get with the current state of the art, but we are getting to the point where this kind of information can be explored interactively with questions and AI codegen, instead of being kept in a fixed document that has to be updated manually (and usually isn't anyway) and hand coded.
- DonHopkins 1y agoI agree they should learn from DLLs, gRPC, SOAP, IDL, dCOM, etc. But they should also learn from how NeWS was better than X-Windows because instead of a fixed protocol, it allowed you to send executable PostScript code that runs locally next to the graphics hardware and input devices, interprets efficient custom network protocols, responds to local input events instantly, implements a responsive user interface while minimizing network traffic. For the same reason the client-side Google Maps via AJAX of 20 years ago was better than the server-side Xerox PARC Map Viewer via http of 32 years ago. I felt compelled to write "The X-Windows Disaster" comparing X-Windows and NeWS, and I would hate if 37 years from now, when MCP is as old as X11, I had to write about "The MCP-Token-Windows Disaster", comparing it to a more efficient, elegant, underdog solution that got out worse-is-bettered. It doesn't have to be that way! https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47 https://donhopkins.medium.com/the-x-windows-disaster-128d398... It would be "The World's Second Fully Modular Software Disaster" if we were stuck with MCP for the next 37 years, like we still are to this day with X-Windows. And you know what they say about X-Windows: >Even your dog won’t like it. Complex non-solutions to simple non-problems. Garbage at your fingertips. Artificial Ignorance is our most important resource. Don’t get frustrated without it. A mistake carried out to perfection. Dissatisfaction guaranteed. It could be worse, but it’ll take time. Let it get in your way. Power tools for power fools. Putting new limits on productivity. Simplicity made complex. The cutting edge of obsolescence. You’ll envy the dead. [...] Instead, how about running and exposing sandboxed JavaScript/WASM engines on the GPU servers themselves, that can instantly submit and respond to tokens, cache and procedurally render prompts, and intelligently guide the completion in real time, and orchestrate between multiple models, with no network traffic or latency? They're probably already doing that anyway, just not exposing Turing-complete extensibility for public consumption. Ok, so maybe Adobe's compute farm runs PostScript by the GPU instead of JavaScript. I'd be fine with that, I love writing PostScript! ;) And there's a great WASM based Forth called WAForth, too. https://news.ycombinator.com/item?id=34374057 https://news.ycombinator.com/item?id=34374057 It really doesn't matter how bad the language is, just look at the success and perseverance of TCL/Tk! It just needs to be extensible at runtime. NeWS applications were much more responsive than X11 applications, since you download PostScript code into the window server to locally handle input events, provide immediate feedback, translate them to higher level events or even completely handle them locally, using a user interface toolkit that runs in the server, and only sends high level events over the network, using optimized application specific protocols. You know, just what all web browsers have been doing for decades with JavaScript and calling it AJAX? Now it's all about rendering and responding to tokens instead of pixels and mouse clicks. Protocols that fix the shape of interaction (like X11 or MCP) can become ossified, limiting innovation. Extensible, programmable environments allow evolution and responsiveness. Speed run that!
- cmrdporcupine 1y agoIt reminds me a bit of LSP, which feels to me like a similar speed-run and a pile of assumptions baked in which were more parochial aspects of the original application... now shipped as a standard. And yeah, sounds like it's explicitly a choice to follow that model.
- airspresso 1y agoYes the authors openly acknowledge [0] to be inspired by LSP. [0]: https://www.latent.space/p/mcp https://www.latent.space/p/mcp