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

Annotations already cover read-only, idempotent, closed-world, non-destructive behavior, so the bar is lower. The description adds genuine runtime context the annotations cannot: the rate vintage/COLA, the rule that dependency add-ons only begin at 30 percent, and the IMPORTANT directive to surface calculator_url as a clickable markdown link — a non-obvious output-handling requirement.

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 primary output (monthly + annualized compensation) before rate details and usage guidance. Three sentences are mostly justified, though the parenthetical rate/COLA detail and the all-caps IMPORTANT block make it slightly dense for a two-parameter calculator.

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 a 100% covered schema and an output schema, the description needs only to add what structured fields lack — and it does: rate vintage, valid rating range, dependency threshold, and the required handling of calculator_url from the result. Nothing needed to call the tool 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% with enum values and descriptions, so the baseline is 3; the description rises above it by stating the valid rating range (10 to 100) and the conditional constraint that dependents only matter at 30 percent or above, which the schema 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 specific verb and resource (VA disability compensation) and pins the scope precisely: monthly plus annualized amounts, 2026 rates with a 2.8% COLA, ratings 10-100, and dependent status. 'VA disability' is clearly distinguishable from the many sibling money calculators such as calculate_military_retirement_pension or calculate_gi_bill.

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?

Explicitly says 'Use when the user wants VA disability compensation for a combined rating and dependents from the 2026 rates,' which gives clear invocation context and implicitly excludes other benefit calculators. It does not name an alternative tool or state when NOT to use it (e.g., a different rate year), 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.