2 ms·
Anyone who has worked with LLMs for non-trival tasks know how poorly they handle JSON vs other formats (they do notably well with XML for some reason but even Y
by CSMastermind 1y ago
Anyone who has worked with LLMs for non-trival tasks know how poorly they handle JSON vs other formats (they do notably well with XML for some reason but even YAML seems to be handled fine).
MCP forcing JSON for tool specifications seems like a massive mistake.
Maybe Google can save us with something built on top of protobuffs.
- progbits 1y agoThe entire MCP mess is not even necessary with protobufs. Just give the LLM a gRPC server endpoint. Done. No need to invent protocol for listing the tools or listing their schema. Just ask the gRPC server for the supported methods, look at the protobuf schema. This is mostly solved and supported out of the box. One potential improvement would be to have the server reply with original protobuf source, including comments, for even better semantic understanding. No need for the absolute disaster of multiple HTTP requests + SSE, servers which need state to deal with session ids and all the problems that causes. It's just a gRPC channel and streaming methods. And auth? Just shove credentials into the metadata. We can standardize that format, or have server reply what it supports. Sigh... I feel like ten years ago garbage like this would be ignored or replaced with something actually sensible. But now nobody cares or feels the pain of the bad spec, they just vibe code some more mess on top of it and keep growing the ~ecosystem~ swampland.
- pcwelder 1y agoGood MCP clients avoid having LLMs generate JSON. Claude for example uses XML to generate mcp tool usage. At least top level strings don't need to be json encoded.