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

Despite annotations being present, the description adds substantial behavior the annotations cannot convey: the three status states and their timing (sealing takes minutes), the prerequisite dependency on delegate_sealing, the quirk that a never-received statement is answered like a pending one, the ten-minute escalation, and the explicit non-sleeping retry contract. The only unreconciled point is that readOnlyHint=false is not explained for what is nominally a status check.

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?

Purpose is front-loaded, followed by the state definitions and then the caveats, and each sentence carries real information (state semantics, sealing timing, the never-received quirk, retry pacing). It is dense as a single paragraph, but nothing is wasted.

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?

With no output schema, the description carries the full return-value burden and does so: it enumerates every expected answer, describes what each means, and covers the unexpected-answer path and the false-pending staleness case. Combined with the retry-pacing guidance, an agent has everything needed to call and interpret it.

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% and the single parameter already documents both its origin ('the content hash register_statement returned') and its format (64 lowercase hex). The description's 'by its content hash' restates that provenance without adding syntax or format detail, so the baseline of 3 applies.

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 and resource ('One status check for a registration, by its content hash') and then defines the exact result space (pending / awaiting_seal / sealed / problem). This lets an agent distinguish it from siblings like register_statement and verify_registration without opening any schema.

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?

Gives clear operating context: it is a single poll ('Does not sleep; pace the retries yourself'), it names the prerequisite that must run before sealing can occur ('never happens until delegate_sealing has run for the log'), and it sets a ten-minute escalation heuristic. It never names an alternative tool or an explicit when-not-to-use case, 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?

Annotations already declare readOnly=false, openWorld=true, idempotent=false, destructive=false, so the safety profile is covered. The description adds real behavioral value beyond that: the conditional chained call to canopy's prepare when the coordinator hasn't learned the public root, the one-time-per-log nature, and that the delegation expires at the returned expiresAt. Auth/grant context is largely left to 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?

Purpose is front-loaded, then consequences, then the chained prepare step, then the authority variant. Dense but every sentence carries information for a six-parameter tool. Slightly run-on phrasing but no wasted 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?

For a mutation tool with no output schema, the description covers the effect, the conditional prerequisite call, the lifetime of the result, and the key/variant distinction. Combined with 100% schema coverage, an agent has what it needs; minor gaps remain around failure modes and permission requirements.

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 six parameters thoroughly, including the as enum and env-var fallbacks. The description restates the 'as: authority' semantics but adds no syntax or format detail beyond what the schema provides; baseline 3 applies.

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 and resource: 'Authorise the operator's sealer to publish checkpoints for your data log, signed with the log key.' The scope and effect are unambiguous, and the authority variant is distinguished from the default data-log behavior. No sibling tool is named for contrast, so it stops just short of full sibling differentiation.

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?

Gives clear context: 'Without it entries sequence but are never sealed' explains why the tool is needed, and 'Run once per log' sets a usage constraint. It does not name alternatives or explicit when-not conditions relative to siblings like register_grant or issue_grant.

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?

Adds real behavioral context beyond the annotations: creation on first use (which explains readOnlyHint=false), the idempotent nature of re-fetching, output formats (ES256, 64 bytes x‖y, hex/base64/SPKI PEM), and the security property "Never returns private key material." That is genuinely non-obvious disclosure, though it does not touch auth requirements or error modes.

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?

Front-loads the core action and return shape before drilling into the variants, with no filler sentences. The prose is dense and slightly run-on with nested clauses, but every clause carries 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 single optional enum parameter with full schema coverage, present annotations, and no output schema, the description supplies everything needed: what is returned, in what encodings, the side effect, and the security guarantee. Nothing an agent needs to call it correctly 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?

Schema coverage is 100%, so the baseline is 3; the description earns above baseline by explaining downstream implications of the choice (a grant naming another key cannot carry statements this server signs; "authority" signs grants that issue_grant makes). This adds meaning the enum label alone does not convey.

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 precise verb and resource ("Return the public half of one of this server's keys") and immediately disambiguates the two variants ("log" vs "authority") with concrete operational meaning. An agent can distinguish this key-fetch tool from siblings like issue_grant or register_statement without opening any schema.

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?

Explains clearly what each "which" value selects and notes the default, giving solid context for choice. It stops short of explicit when-to-use/when-not framing (e.g., prerequisites relative to issuing or registering grants), but the variant guidance is unusually rich.

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?

Annotations already declare a non-readonly, non-destructive, non-idempotent local mutation; the description adds real value beyond them by disclosing that the grant is 'saved under a fresh child log id' and that 'nothing is sent', which is critical for understanding this is a local signing step rather than a network publish.

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 action is front-loaded, but the opening sentence is a dense run-on packing parentheticals ('sized with maxHeight, the batch ceiling canopy prices it by') that is hard to parse. The closing next-step sentence is efficient, offsetting some of the bloat.

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 cryptographic grant-issuance mutation with no output schema, the description explains persistence and the follow-up step but never says what the call returns (e.g., the fresh child log id or the signed grant), which an agent needs to proceed to register_grant.

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 four parameters including defaults and the UUID pattern. The description restates grantee default ('this server's own') and the pricing role of maxHeight, adding only marginal meaning beyond the schema.

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+resource: it signs a child data-log creation grant using the server's authority key. It also distinguishes the step from the sibling register_grant by declaring 'Call register_grant next', so an agent can tell issuing apart from registering.

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?

Guidance is largely implied through workflow sequencing: 'Call register_grant next' tells the agent the ordering but never states when this tool is the right choice versus siblings like delegate_sealing or register_statement, and gives no when-not conditions.

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?

The description adds substantial behavioral context beyond the annotations: it explains the 402 payment flow, payer hard caps, testnet-by-default behavior, no-payer requirement response, relay payment via X-PAYMENT, and nonce-derived anti-double-pay protection. Annotations already disclose open-world and non-idempotent behavior, and the description enriches that with concrete operational details.

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 a single dense paragraph, but it is front-loaded with the primary action and then follows the important payment/resume branches. It is long for a tool description, yet the complexity of the registration and payment lifecycle justifies most of the detail.

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, multi-call, payment-aware registration tool with no output schema, the description covers the lifecycle, resume behavior, payment paths, caps, anti-double-pay guarantees, and handoff to delegate_sealing/register_statement. An agent has enough information to call and retry it correctly.

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 six parameters well. The description adds some workflow meaning for logId and payment, but does not meaningfully extend baseUrl, rootLogId, or parentGrant beyond what the schema provides, so the baseline 3 is appropriate.

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 verb and resource: register a child grant with canopy via POST /register/{R}/grants, using the authority grant as parent, and follow it to receipt. It also distinguishes the workflow from sibling tools by naming delegate_sealing and register_statement as downstream consumers of the completed 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 gives clear usage instructions for the multi-step lifecycle: call again with the same logId to resume, handle 402 with or without a configured payer, and use payment mode when paying from your own x402 wallet. It does not explicitly say when not to use this tool or compare it directly to issue_grant, but the context is actionable.

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?

Annotations cover safety (readOnly=false, idempotent=false, openWorld=true), and the description adds real beyond-schema behavior: the 4 MiB canopy limit, that the signed statement is persisted before sending so the content hash remains valid on failure, and that a payload path may not target the log key or the server home. It stops short of stating auth/permission requirements for the grant, so not a 5.

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?

Four dense sentences with the core action front-loaded, followed by input limits, side-effect semantics, and the next step. Every sentence carries information an agent would otherwise have to guess.

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?

No output schema exists, yet the description explains the return value (content hash that always names the saved statement), the size limit, the persistence/async semantics, and the follow-up call — everything needed to invoke and act on the result.

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 100%, so the baseline is 3; the description adds one genuinely non-schema constraint on the payload parameter (a path may not point at the log key or inside the server's home) and notes the 4 MiB ceiling. The remaining five parameters (grant, issuer, baseUrl, subject, rootLogId) get no description-level clarification.

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+resource pair ("Sign a payload with the log key and register it") and names the scoping credential (your Forestrie-Grant), which separates it from siblings like issue_grant or register_grant. An agent can identify the operation without opening the schema.

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?

Gives an explicit workflow handoff: "Registration is accepted, not yet sequenced: call check_registration next." That routes the agent correctly post-call, but it never states when to prefer this over verify_registration, delegate_sealing, or other siblings, so it is clear context without exclusions.

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?

Adds context beyond the annotations: it states verifying never creates a key (a meaningful side-effect clarification given the sibling key/register tools), and explains the default trust root and the split-view capability tradeoff. Annotations already cover readOnly/idempotent/destructive, so this is supplementary value rather than essential disclosure.

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?

Two dense sentences with no filler, and the default case is stated before the optional override. Package names and 'four-question answers' jargon cost a little readability but nothing is redundant.

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?

No output schema exists, so the description must carry the return-value burden; 'return its four-question answers unaltered' hints at a structured verification result but never defines what those four answers are. For a verification tool whose output shape matters, that is a notable gap.

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 100% so the baseline is 3, but the description adds real meaning the schema cannot: why knownAccumulator exists, where to get it, and what capability it unlocks (split-view answers) versus the server-key default. contentHash is not elaborated but is well documented in the schema.

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 (verify) and resource (a sealed registration's receipt over a registered statement), and names the verifier used. It does not contrast itself with the sibling check_registration, so the agent must infer the distinction, but the core action is unambiguous.

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?

Gives conditional guidance: default is the server's own log key, and pass a knownAccumulator (sourced from fetch_accumulator) only when you need a root that can also answer split-view. It lacks explicit when-not rules or a comparison against check_registration, but the parameter choice is well motivated.

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