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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses a critical security property ('THIS SERVER NEVER SEES YOUR KEY'), clarifies that the result is an unsigned digest rather than a broadcast transaction, and explains the authority conservation invariant ('authority is subdivided, never created'). It does not cover every possible behavioral aspect, such as error handling or response format, but it covers the most important operational traits.

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?

Three dense sentences, each earning its place. The core action and deliverable are front-loaded, followed by the security guarantee and the non-obvious allowlist constraint. There is no filler or restatement of schema content.

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 is complex, with 14 parameters, nested objects, and no output schema. The description is helpful but not fully complete: it does not specify the digest's encoding or format, what to do after signing, how feeSompi and computeBudget behave, or error conditions such as stale UTXO. For a transaction-building tool, an agent would still need additional guidance to confidently construct and finish the flow.

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?

The schema covers roughly 64% of parameters, and the description adds meaningful semantics beyond that. It explains why parentRecipients is sometimes required, what childRecipients means relative to the parent's allowlist, and why childDelegationDepth must be strictly lower. This is genuine conceptual value, even though a few parameters like feeSompi and computeBudget remain unexplained.

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 states a precise verb and resource: 'Assemble an unsigned transaction that subdivides this grant into a child for a sub-agent' and specifies the deliverable, 'return the digest to sign with the PARENT's agent key.' This distinguishes the delegation builder from sibling tools like warda_build_spend or warda_build_exit, which handle different operations on the same grant.

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 makes the intended use clear: it is for subdividing an existing grant into a more restrictive child delegation. It also gives an important usage condition: narrowing the child's allowlist requires passing the parent's full member list. It does not explicitly contrast this tool with alternatives such as warda_build_spend or warda_build_settlement, but the specialization is evident enough for an agent to route the task correctly.

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