tree_solve

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations available, the description carries the full behavioral burden and does so thoroughly. It discloses sandboxing, the different read scopes of native contracts versus wasm modules, the diagnostic/proposal return shape, provenance stamping, and the crucial fact that nothing is written. It also states how accepted proposals should be applied via tree_set.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core operation and then layers in only useful distinctions: sandboxing, visibility scope, return shape, write behavior, and the local-execution alternative. Every sentence adds information, and the parenthetical about native versus wasm read scope is compact and relevant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema, so the description need not fully explain return values, but it still helpfully summarizes diagnostics and proposals. It covers the operation's side effects and apply-via-tree_set workflow well. The main remaining gap is that `params` is not explained despite 0% schema description coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description needs to compensate. It explains `path` by noting that wasm sees only the slice at that path, and `name` is implicitly the registered solver name. However, the important `params` object is never described, so a caller cannot tell what solver-specific parameters are expected or how they are interpreted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: run a registered solver on a branch it may read. It explains the two solver kinds and contrasts native-contract visibility with wasm visibility at `path`. It also distinguishes the operation from writing by stating that proposals must be applied with tree_set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: the solver must be registered, it may read a branch, and the operation produces proposals rather than writes. It names tree_set as the alternative for applying accepted proposals and mentions fetching the wasm module to run locally. It does not explicitly state when to prefer local execution over this tool, but the alternatives are concrete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.