My thinking so far is that Sonde only tries to describe the capability surface of the tool: commands, inputs, outputs, and discovery. In other words, what the tool can do in principle.
Authorization feels like it belongs to a different layer that sits between the agent and the tool: something that can apply task context, policies, or sandbox constraints before execution.
So the manifest would help the agent construct a valid call, but it shouldn't imply that the call is allowed. The enforcement layer still decides that.
Your filesystem example is a good illustration: the manifest could describe `delete_file`, but whether the agent is allowed to call it on a specific path would depend on the environment or policy around the tool.
Right now I'm mostly exploring the capability contract because that surface feels under-specified in current tooling. But I agree that the authorization layer is where a lot of the real safety and control questions live.
This project was inspired by a tweet from Guillermo Rauch referencing the article
“Rewrite your CLI for AI agents”.
The idea is simple: most CLIs were designed for humans reading terminal output.
AI agents interacting with tools need something closer to a machine-readable contract.
Sonde is an early experiment exploring a small manifest that lets tools describe
their commands, inputs and outputs so agents can discover and execute them
without scraping terminal output.
This is still very early and I'm mainly interested in feedback from people building developer tooling or agent workflows.
My thinking so far is that Sonde only tries to describe the capability surface of the tool: commands, inputs, outputs, and discovery. In other words, what the tool can do in principle.
Authorization feels like it belongs to a different layer that sits between the agent and the tool: something that can apply task context, policies, or sandbox constraints before execution.
So the manifest would help the agent construct a valid call, but it shouldn't imply that the call is allowed. The enforcement layer still decides that.
Your filesystem example is a good illustration: the manifest could describe `delete_file`, but whether the agent is allowed to call it on a specific path would depend on the environment or policy around the tool.
Right now I'm mostly exploring the capability contract because that surface feels under-specified in current tooling. But I agree that the authorization layer is where a lot of the real safety and control questions live.