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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a modest scope boundary ('does not calculate or submit'), which is genuinely useful, but it never explains how the conditional-schedule logic resolves or what the readiness verdict contains.

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 tight sentences with the positive scope statement front-loaded and the exclusion trailing; nothing is redundant. The economy is appropriate, though the brevity leaves substance on the table for a 21-parameter tool.

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 should carry the burden of describing the readiness result, and it does not. For a 21-parameter tool with 8 required booleans and a nested audit object, the two-sentence description is far short of what an agent needs to invoke it confidently.

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 0% across 21 parameters, so the schema itself explains nothing. The description only gestures at categories ('source records, finalised accounts, official worksheets, conditional schedules') without mapping any of the booleans (recordsKept, businessComputationReady, personalReliefEvidenceReady, etc.), the audit object, the taxYear default, or the assessmentType 1-5 codes.

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 (Check/Assess) and resource (readiness of inputs for manual Form B 2025 preparation), clearly framing it as a diagnostic pre-check. It does not, however, distinguish itself from the sibling 'prepare_be_2025_draft' or explain that it is the precursor step, so sibling differentiation is left implicit.

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 'does not calculate or submit Form B' clause implies this is a pre-flight check to run before actual preparation, and the sibling 'prepare_be_2025_draft' suggests the natural pairing. But there is no explicit when-to-use statement, prerequisite list, or named alternative, so usage is only inferred.

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