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

The annotations already establish read-only, idempotent, non-destructive, and closed-world behavior. The description adds meaningful behavioral detail about weekend/holiday adjustment rules and the fallback to the statutory date with adjusted: false. It does not discuss authentication, rate limits, or response structure, but the adjustment semantics are the key behavioral context for this tool.

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?

The description is a single front-loaded sentence that efficiently conveys the core purpose and adjustment behavior. The semicolon-delimited fallback clause is dense but informative. No sentence feels wasted, though the sentence is somewhat long and could be split for readability.

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 simple three-parameter lookup tool with annotations covering safety and idempotency, the description is largely complete. It explains the main behavioral nuance around weekend/holiday adjustments and the fallback adjusted: false. It does not describe returned fields or provide explicit alternative-tool guidance, but those gaps are minor for this tool.

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 only 33%, with only country described in the schema. The description adds some meaning via 'given month' and 'country's rule,' but it does not clarify year usage or the month range beyond what the schema constraints already state. It partially compensates for the coverage gap but not enough to raise the score above the baseline.

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 states a specific verb and resource: retrieving tax filing and payment due dates. It adds scope details such as the given month and the tax types covered (VAT, PAYE, withholding, corporate tax). It does not explicitly contrast itself with siblings like get_public_holidays or add_business_days, keeping it from a 5.

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?

Usage is implied by the required country, year, and month scope, but the description gives no explicit when-to-use or when-not-to-use guidance. It does not name alternatives such as get_public_holidays for holiday lookup or calculate_withholding_tax for tax computation.

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