3 ms·
Isn't MPC based on JSON-RPC?
by MuffinFlavored 1y ago
Isn'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...