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

Read-only/idempotent annotations already cover safety, and the description adds meaningful behavior: it returns eligibility plus any shortfall, it is an estimate rather than legal advice, and it points to the full interactive calculator. No contradiction with 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?

Three sentences front-load the core purpose and rule, then cover input/output and the legal caveat. The long tracking URL is the only slightly heavy element, but every sentence earns its place.

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?

Given the output schema exists and the four parameters are fully documented in the input schema, the description supplies all significant context: the legal rule, date format, return semantics, and an explicit disclaimer. Nothing an agent needs to invoke it successfully 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%, so the baseline is 3, but the description adds interpretive value beyond the schema: 'pre-PR half-day credit capped at 365' explains how temporary_resident_from is used and why the calculation is not just post-PR days. This compensates for the schema's terse parameter descriptions.

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 description identifies a specific verb/resource ('physical-presence calculator for Canadian citizenship eligibility') and names the exact statutory rule (1,095 days in 5 years) plus the pre-PR half-day credit. This makes it unmistakable among the sibling tools, none of which are presence calculators.

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 description gives clear context for when to invoke it: to compute physical-presence eligibility for Canadian citizenship, with results as of the application date and shortfall. It does not explicitly spell out when-not-to-use or name alternatives, so it stops short of a 5, but the sibling list has no competing calculator.

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