why can't this be a cli tool? then you can get an agent to write a script that programmatically calls the cli tool in addition to the agent calling it directly.
It could be a cli tool, and it should be a cli tool, for exactly this reason.
Let the LLM work in code mode. Don't make it have to be the execution engine too. It can do it but it's slow and giving it tools script what it wants will go far better.
I do think there's an interesting possibility where we turn MCP into something composable. Capnproto has promise pipelining where you can issue new instructions with results you don't have yet. If MCP could copy those tricks, & express promises... and those promises worked across MCP servers ("third party handoff", https://github.com/capnproto/go-capnp/issues/597)... you'd start to have something as compellingly composable as the shell.
It could be a cli tool, and it should be a cli tool, for exactly this reason.
Let the LLM work in code mode. Don't make it have to be the execution engine too. It can do it but it's slow and giving it tools script what it wants will go far better.
I do think there's an interesting possibility where we turn MCP into something composable. Capnproto has promise pipelining where you can issue new instructions with results you don't have yet. If MCP could copy those tricks, & express promises... and those promises worked across MCP servers ("third party handoff", https://github.com/capnproto/go-capnp/issues/597)... you'd start to have something as compellingly composable as the shell.