Client side tool execution

[badlogic]

File System is a way for the agent to call tools on the client side. While the shape of inputs is generic (method field), it is currently limited to two specific tools: fs/read_text_file and fs/write_text_file.

I have a different use case where the client has a sort of canvas the agent could interact with (think Claude's artifacts, ChatGPT's canvas, etc., which are all implemented browser-side). The agent can use its own tools as well as client-side tools.

It would be lovely if the protocol parts found in File System could be generalized. Clients could advertise their client-side tools to the agent, which in turn can call them along with its own tools. This would be part of the client capabilities check I'd presume.

Then, during a prompt turn, the agent can make tool calls either to client-side or agent-side tools. Agent-side tool calls and status updates would continue to be reported as described in prompt turn. Client-side tool calls would require the client to send updates in the other direction, with the agent waiting for the complete result or failure.

I suppose the only issue with this is that many/most agent SDKs (CC, Gemini, Codex, etc.) only support adding tools via MCP. However, an ACP agent implementation wrapping an agent SDK could "simply" add a generic MCP that exposes any tools reported by the client to the agent SDK and manages communication with the client in case of tool calls to client-side tools.

Thanks for this effort!

[agu-z]

@badlogic The methods in the ACP spec are meant to be accessed programmatically and not given directly to a model, which is MCP's focus.

I think your use case can already be achieved by providing the tools to the model directly via an MCP server, which your Client can specify when it creates or loads a session.