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

Annotations already declare destructiveHint=false, idempotentHint=true, openWorldHint=false, but the description adds substantial context beyond them: one invalid item rejects the entire batch and keeps nothing, rejection is reported as registration_rejected with item-specific repair, chart claims show as claim_unbound until statements are submitted, the chart is absent from list_charts until it is posted, and the call is not metered. The re-registration behavior ('returns its existing row') makes the idempotentHint concrete rather than contradicting it.

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 core is front-loaded and every sentence carries real information, but the body is a dense, heavily parenthesized wall of text — enumerations of declaration types and nested clauses like the claim_unbound explanation are hard to parse on first read. It is informative rather than padded, yet far from tightly structured.

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-phase workflow tool this is essentially complete: it covers admission checking, batch atomicity, the per-document registration id and waiting step, idempotent re-registration, and the handoff to submit and post_chart_accounts. An output schema exists, so not spelling out return values is acceptable.

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 only 50%: workspace_tag and the handle field are documented, but the inline document object has no description anywhere. The description explains the batch-level semantics (one invalid item rejects everything, max batch behavior implied) but never explains the handle-vs-inline choice or what an inline document shape must contain, so it does not compensate for the schema gap.

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 names a specific verb (registers) and the three specific resources (Standard Statements, Standard Charts, Standard Declarations), and immediately scopes it against the whole sibling family: 'Register installs nothing, founds no party and starts no work.' An agent can tell it apart from submit, post_chart_accounts, and create_standard_* 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?

It states the sequencing contract explicitly — 'Register everything, then submit in sets ... and post' — and names the alternatives (submit, post_chart_accounts) along with what each does that register does not. It also gives a concrete when-to-use pattern: batch register, then submit January's statements, then post, checking the books between steps.

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