[upghost]

I think it's interesting and odd that tool calling took the form of this gnarly json blob. I much prefer the NexusRaven[1] style where you provide python function stubs with docstrings and get back python function invocations with the arguments populated. Of course I don't really understand why MCP is popular over REST or CLI, either.

[1]: https://github.com/nexusflowai/NexusRaven-V2

[max-privatevoid]

The actual API call is still going to be JSON. How do you deal with that? Pack your Python function definitions into an array of huge opaque strings? And who would want to write a parser for that?

[upghost]

I'm sure you realize it gets reassembled into "huge opaque strings" when it is fed into the LLM as context. The arbitrary transport of the context as JSON is just a bit of protocol theater.

You don't really have to parse the output, Python already has a parser in the form of the AST library[1].

But I get your drift. Depending on your workflow this could seem like more work.

[1]: https://docs.python.org/3/library/ast.html#module-ast

[max-privatevoid]

The inference engine can do whatever it wants. This is already the case. The actual format of the tool call text varies by model, and the inference engine handles the translation from/to the JSON representation, that's the least of its concerns.

What I don't want to happen is for some shitty webdev who writes an AI client in JavaScript to be forced to write a custom parser for some bespoke tool call language (call it "MLML", the Machine Learning Markup Language, to be superseded by YAMLML and then YAYAMLML, ...), or god forbid, somehow embed a WASM build of Python in their project to be able to `import ast`, instead of just parsing JSON and looking at the fields of the resulting object.

[upghost]

Yeah that's fair, I concede the point.

I got a good snicker out of the YAYAMLMLOLOL :D

Seems like it's tools calling tools all the way down heh