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

Annotations say readOnlyHint=true and the description reconciles that precisely: authoring/sealing does not change the books, only post_chart_accounts does. It adds the validation contract (the exact parser register uses, including chart_mismatch on the document's 'chart' name), the clarification_needed recovery loop, and the cost signal 'model-backed and metered'. That is substantial behavior beyond the annotations.

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 verb, scope, and kind choices before the validation and clarification details. It is fairly dense and has some redundancy with the schema's own property text, but each paragraph carries a distinct idea (what it does, how it validates, what happens when ambiguous, what state changes) rather than padding.

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 7-parameter, nested-schema tool with an output schema, the description covers what an agent needs before calling: scope, kind selection, the two mutually exclusive input arms, validation failure modes, the ambiguity recovery path, and the fact that no books move. Return-value detail is correctly left to the 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 coverage is 100% and the property descriptions already carry 'account codes are not needed', the description/document exclusivity, the chart-name-not-chart_id rule, and the model-call distinction. The description restates these, which is useful corroboration but adds little meaning beyond the schema; the only genuine addition is tying validation to register's parser, which is not per-parameter semantics. 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 — 'Authors one sealed declaration' — and pins its scope ('whose meaning belongs to exactly one chart, selected by chart_id'), which is exactly what separates it from create_standard_declaration_workspace. It also enumerates the three declaration kinds, so an agent knows both what it makes and which variants exist 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 clear when-to-use context: choose one of three declaration kinds, supply ordinary-language description, then review and register the result. It also explains the handoff — nothing changes the books until post_chart_accounts posts the chart — which routes the agent to the posting tool for the actual write. It never explicitly contrasts the two arms (description vs document) as a usage decision, or names the workspace-scoped sibling, which keeps it off a 5.

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