warda

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.

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

With no annotations, the description carries the full burden of behavioral disclosure, and it communicates key traits: the transaction is unsigned, the server never sees a key, revoke is effective immediately once confirmed, and reclaim is CLTV-gated. It also discloses that the agent cannot stop or outrun a confirmed revoke. This is strong coverage, though it does not describe error conditions or returned data shape.

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 essential action and then expands into the two modes, key safety, and intended use case. Every sentence adds semantic value, though the phrasing 'cannot outrun it beyond the limits it already had' and the uppercase safety line add rhetorical emphasis rather than new information.

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?

For a moderately complex builder with nested objects and no output schema, the description is nearly sufficient: it explains purpose, the two operational modes, timing guarantees, and key handling. It does not explicitly describe the returned unsigned-transaction shape or clarify how `feeSompi` and `computeBudget` should be chosen, but nothing essential to selecting the tool or invoking the main parameters is missing.

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 description adds meaningful semantics to the `kind` parameter by explaining what revoke and reclaim do and which key signs each, and it reinforces `lockTime` via the CLTV window. However, with only 50% schema description coverage, the optional `feeSompi` and `computeBudget` parameters receive no added context, and many nested grant fields are left to their names.

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 opens with a specific, concrete action: 'Assemble an unsigned transaction that ENDS this grant and sweeps its balance to the principal.' This precisely identifies both the resource (the grant) and the outcome (ending it), and clearly differentiates it from sibling builders like warda_build_spend or warda_build_settlement, which would not terminate the 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?

It explicitly frames when to use it: 'the tool a monitor calls when a grant is behaving badly and something has to act.' It also separates the two modes—revoke for immediate emergency stop, reclaim for after the window has closed—and even notes that an early reclaim 'simply will not run.' It does not name sibling alternatives explicitly or state when not to use this tool beyond those timing constraints.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses that the transaction is unsigned, that two digests are returned, which key signs each half, that the server never sees the digests, and that prevRoot comes from a prior delegation and cannot be derived on-chain. This is meaningful behavioral context beyond the schema.

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 dense but not bloated; every sentence contributes either purpose, differentiation, return behavior, or parameter provenance. The main action is front-loaded, and the technical hash-chain note is relevant rather than decorative. It is slightly longer than necessary, but the added context earns its place.

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?

For a complex tool with nested objects, eight parameters, no output schema, and no annotations, the description covers the core workflow, return values, signing model, and the tricky prevRoot dependency. It does not spell out every parameter's format or failure cases, but it gives enough for an agent to understand the transaction shape and where to obtain the required prior value.

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 coverage is 63%, and the description adds crucial semantics for prevRoot: where it comes from, why the delegation tool is the source, and why it cannot be reconstructed from chain data. It also clarifies the split-signing behavior, which helps agents understand how parent and child keys map to outputs. Not every parameter is elaborated, but the highest-risk parameter gets strong treatment.

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-resource pair: it assembles an unsigned transaction that ends a child grant and returns the unspent remainder to the parent's budget. It clearly distinguishes settlement from simply letting a child expire, and even names warda_build_delegation as the source of prevRoot, so an agent can tell this apart from its siblings.

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 explains when settlement is appropriate: it is the useful mid-task counterpart to letting a child expire, which returns money to the principal instead of the parent budget. It also references warda_build_delegation for obtaining prevRoot. It does not explicitly state all alternative tools or exclusion cases, but the key contextual contrast is present.

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

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

With no annotations, the description carries the full burden, and it delivers: it explicitly states the server never sees the key, never signs, returns a digest for local signing, returns an advisory verdict but builds regardless, and warns that broadcasting a refused verdict will fail and cost a fee. These are exactly the non-obvious behaviors an agent needs before calling.

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?

Every sentence earns its place: first sentence states the operation and result, second addresses the critical security boundary, third explains the advisory verdict and consequences. The most important action is front-loaded, and there is no filler.

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 description provides sufficient context for invoking the tool: what is built, what is returned, and the failure consequences. Minor completeness gaps remain, such as not describing the shape of the returned digest/verdict or the need for a current UTXO, though the schema covers the UTXO requirement and there is no output schema.

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 100%, so the schema already documents all parameters; the description adds no field-level meaning beyond that baseline. It says nothing about how to format values or how parameters relate to the returned digest, so the score stays at the baseline.

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 first sentence states a specific verb ('Assemble'), a concrete resource ('unsigned Kaspa transaction that spends from this grant'), and the primary result ('return the digest to sign'). This clearly separates it from sibling build tools such as delegation, exit, and settlement, since the action is specifically spending from a grant as a payment.

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 implies when to use it: whenever a payment from a grant needs to be built and signed. However, it does not explicitly mention alternatives or exclusions, despite the presence of eight sibling tools, and it never says 'use this instead of check_spend/build_settlement'; the guidance is more implicit than directive.

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

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

With no annotations, the description carries the behavioral burden. It communicates that this is an advisory check and that delegation authority is subdivided, never created. This gives the agent a meaningful sense of side-effect-free validation, though it does not specify the response format or whether any verification state is involved.

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 compact and front-loaded with the main purpose. Every sentence adds value, and the domain invariant is stated efficiently. There is no redundant filler.

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?

Given the high complexity of the nested parent schema, six required parameters, and no output schema, the description is not complete enough. It does not explain how to determine the parent state, what daaScore represents, what a valid result looks like, or what inputs the caller must supply beyond the obvious child budget fields.

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 only 17%, so the description needs to compensate for parameter meaning. It explains the parent/child relationship in general terms, but it does not clarify the semantics of key parameters such as daaScore, childAgentKey, or how the child budget fields map to the legal-narrowing rule.

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 specific action (check) on a specific resource (proposed child grant) and defines the core criterion: whether it is a legal narrowing of the parent. It also explains the underlying rule clearly. This differentiates it from sibling build/check/spend tools.

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 implies when to use the tool: to validate a proposed child delegation before or without building it. It labels the tool as advisory, which suggests it is safe to call for pre-validation, but it does not explicitly mention alternatives or when not to use it.

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

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 explains that the tool evaluates against every covenant rule, returns the chain's verdict, and automatically builds the recipient proof. The advisory warning that 'permitted' is not permission adds important behavioral nuance. It does not explicitly state that the tool has no side effects or broadcasting behavior, but 'check' and 'advisory' strongly imply a non-mutating evaluation.

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 compact and front-loaded: the first sentence states the action and outcome, the second mentions a useful support behavior, and the third conveys an essential advisory nuance. Every sentence earns its place without unnecessary length or repetition.

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?

For a complex tool with a nested grant object, no annotations, and no output schema, the description covers the core behavior and the two possible verdicts. However, it does not explain what daaScore means, how to supply a valid grant state, or the exact structure of the returned verdict beyond 'permitted' and 'refused.' The description is adequate for understanding the tool's purpose but incomplete for fully confident invocation in edge cases.

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 already documents amountKas and recipient with descriptions, and the grant has a brief top-level description. The tool description does not add much meaning beyond what the schema provides, and daaScore is left semantically unexplained. With approximately 75% schema description coverage, a baseline of 3 is appropriate; the description adds some framing but does not compensate fully for the undocumented daaScore parameter.

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: 'Check a proposed payment against every rule the covenant enforces' and states the key output, 'return the same verdict the chain would.' This clearly distinguishes the tool from the sibling builders like warda_build_spend by focusing on evaluation rather than construction. The title 'Would this payment be allowed?' reinforces the intent.

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 contextual guidance: this is an advisory check before broadcasting, and it explains the meaning of both 'permitted' and 'refused' outcomes. It does not explicitly name sibling alternatives or state when not to use the tool, but the advisory framing and 'proposed payment' language imply the appropriate use case.

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

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 correctly warns that the address is a hash of state and 'MOVES after every spend and every delegation — an address that worked yesterday holds nothing today.' This is critical, non-obvious behavior that an agent must know. The description does not claim any mutation or side effect, which is consistent with a pure derivation operation.

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 sentences, each earning its place: purpose, key behavioral warning, and usage guidance. The most critical fact (address moves with state) is front-loaded in the second sentence. There is no fluff or repetition of schema contents.

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?

For a two-parameter tool with rich schema documentation and no output schema, the description is adequately complete. It states what is computed, what inputs matter, why the operation is state-sensitive, and when to use it. The only minor omission is an explicit statement of the return value format, but 'on-chain address' plus the prefix parameter in the schema make this sufficiently clear.

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 input schema already provides descriptions for both parameters and for reserveRoot, giving 100% coverage, so the baseline is 3. The description adds meaningful conceptual semantics beyond the schema: it explains that the address depends on 'current state' and is a hash of the state, which is why the nested state object must be accurate. This helps the agent understand how to populate the `grant.state` sub-object correctly.

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: 'Derive the on-chain address of a grant from its terms and current state.' This makes the tool's function unmistakable and differentiates it from sibling tools that build/check spend, delegation, settlement, or recover operations. The title also reinforces the purpose conversationally.

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 states a clear use case: 'Use this to know which address to fund, watch, or look up.' It does not explicitly name alternatives, but the sibling set contains operations that are materially different (building transactions, checking statuses, recovering grants), so the intended context is clear and unlikely to be confused.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It does so well by stating this is advisory and that limits are enforced whether or not the agent asks, which clarifies this is a read-only/informational call. It could add more detail about side effects or authorization requirements, but the advisory framing is substantive.

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 two sentences with no filler. The first sentence front-loads what the tool reports, and the second provides use context and important advisory behavior. Every clause earns its place.

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?

Given there is no output schema, the description appropriately lists the return content in user-facing terms and gives clear invocation context. It is slightly light on exact output shape or examples, but the combination of a 100%-covered input schema and a descriptive two-sentence summary is sufficient for correct selection and invocation.

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 100%, so the schema already documents grant and daaScore adequately. The description adds high-level meaning by linking the reported values to grant parameters, but it does not need to elaborate further because the schema covers the parameter semantics.

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 names a specific action ('Report') and a clear resource ('a grant's remaining authority'), then enumerates the exact outputs: budget left, epoch headroom, per-transaction cap, and largest single payment permitted now. This clearly differentiates it from sibling build/check tools, which construct or inspect transactions rather than report spending capacity.

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 explicit context for when to use the tool: 'Use this before planning a purchase.' It also notes the advisory nature, indicating the covenant enforces limits regardless. It does not explicitly name alternatives or when not to use it, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the burden; it explains the underlying protocol fact that 'every spend publishes the grant it spent' and that recovery is possible from wire JSON or redeem script hex. This makes the read-only, non-database source of data transparent. It stops short of describing failure modes or exact output, but the operation's behavior is clearly disclosed.

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 opens with the purpose, then the use case, then the protocol justification, then input guidance — a sensible front-loaded order. Each sentence contributes new information, though it is slightly longer than strictly necessary. No filler or repetition of schema field names.

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?

For a read/recovery tool with no annotations and no output schema, it explains the input options, the conditions under which to use it, and why recovery works. It does not describe the shape of the returned grant state or behavior when inputs are missing or invalid, so an agent still must infer some result semantics. This gap keeps it from being complete, but it covers the essential call-time decisions.

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 already documents all three parameters (100% coverage), so the baseline is a 3. The description adds value by clarifying that `transaction` and `redeemScriptHex` are alternatives and by specifying wire-JSON format for the transaction. This exceeds what the schema descriptions alone provide.

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?

States a specific verb ('Read'), a specific resource ('a grant's full state'), and the recovery source ('any transaction that spent it'). It also names the intended outcome ('work out where it went'), which clearly distinguishes it from the build/check/grant sibling tools.

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?

Explicitly defines the trigger: 'Use this when a grant's recorded state is stale, wrong, or lost and its address turns up empty.' It also tells the agent what inputs are acceptable in which situation ('transaction as wire JSON, or just the redeem script hex'). It does not name alternative tools, but the trigger condition is specific enough to route away from the siblings.

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