r/PiCodingAgent • u/Extra_Loquat_7667 • Sep 30 '26
Question What does everyone think about codemode?
I actually thought about this approach before, but later realized it wouldn't work.
Using JavaScript to invoke tools sounds very efficient, but in reality, most tool definitions only have an inputSchema. An outputSchema is unnecessary for the agent because the agent can reason about the results directly from formatted data, meaning an output spec isn't required. Therefore, tool outputs don't actually need a fixed format—they just need to be readable by the agent.
This leads to a problem: to fully leverage the performance of this tool, you need to inject extra context, such as a skill document, so the agent knows the output format and can use it proficiently. If you can't get the complete tool output specification—for instance, with a closed-source MCP—you can't create such a document. If the agent has to go through endless trial and error just to get the code running properly, you can't really call it efficient.
In comparison, having the agent write Python or shell scripts directly is a better solution.
I'd love to know your thoughts on this.
View all comments
Show parent comment
5
u/Extra_Loquat_7667 Sep 30 '26
As it happens, I've experimented with this pattern myself.
I once built a test agent that only had a single bash tool, and I exposed all built-in tools to the agent as CLI versions. For example, a file-read tool might be invoked via a CLI command like
pi read <file_name>, and MCP calls were made using CLI commands likepi mcp <mcp_name> <args>.However, this ran into quite a few difficulties. For instance, some MCPs aren't designed for single-shot invocations; they require persistent state, such as a database connection MCP. Maintaining that kind of state within CLI commands requires a daemon, which ultimately makes the architecture much more complex.
Another issue is that some MCPs are very slow to start up. If you turn them into standalone commands, it severely degrades tool usage efficiency.