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

Annotations cover safety (readOnlyHint=false, destructiveHint=false) and idempotency, and the description adds value beyond them: 'A returned taskId proves admission, not settlement; persist it and poll tasks_get at pollIntervalMs' discloses the async lifecycle, and 'Submitting the same set again replays its outcome' explains the idempotent behavior rather than merely restating the hint. It also flags metering ('bills to the workspace owner') and a recovery path (list_submissions) — exactly the operational context annotations cannot express.

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-loaded with the core action and the post_chart_accounts exclusion, then lifecycle and billing details in descending priority. It is a single dense block with some compressed clauses (the refusal sentence in particular), but essentially every sentence carries distinct operational information rather than restating structured fields.

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?

An output schema exists, yet the description still covers the one return fact an agent must act on — taskId is admission, not settlement, and must be persisted and polled. Combined with refusal cases, idempotent replay, and billing, nothing material for correct invocation 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 description coverage is 100%, so the schema alone would justify a baseline 3. The description goes further, adding selection order ('oldest first'), the batch cap ('at most 100 per call'), and the precise meaning of the 'all' default ('every one not yet submitted') — semantics an agent needs that the schema's const/enum shape 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?

Opens with a specific verb+resource+scope: 'Processes registered documents as one durable FinStat Task.' It immediately delimits what this does not do ('it posts to no chart: post_chart_accounts does'), so an agent can separate it from the sibling that actually posts to a chart without opening either 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?

Explicit when-to-use guidance ('Submit in sets to keep control: January's statements, check, then the next set') and explicit when-not guidance ('Naming a chart, a journal-entry declaration or a retirement is refused with a pointer to post_chart_accounts (not_submittable), as is a set with nothing left to submit'). It names the alternative tool and the exact condition that selects it.

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