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

Annotations already declare readOnly/openWorld/non-idempotent, so the bar is lower, and the description adds genuinely useful context the annotations don't cover: the pricing model ($0.001 USDC per call, x402 or prepaid credits) and that it is in the free trial. It does not, however, address the non-idempotent hint or explain response shape beyond what the output schema covers.

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-loads purpose and resource, then lists use cases, then pricing — good ordering with no wasted sentences. It is slightly dense with parenthetical asides, but each clause carries distinct information.

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 full schema, full annotation set, and an output schema, the description needn't explain return values, and it covers the multi-mode nature of the tool plus payment details. Minor gap: it doesn't state the division/coverage caveat that results vary by nation (three enum values) beyond listing the divisions.

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 combinatorial meaning the per-field schema does not: it implies date alone = single-day check, from+to = working-day count and holiday list, and addWorkingDays = date offset. This mapping helps an agent pick the right mode rather than just understand individual fields.

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 resource (official UK bank holidays from GOV.UK) plus the concrete operations it supports: check a date, next holidays, working days between dates, and N working days after a date. An agent can distinguish this from every sibling tool (no other holiday/calendar tool exists in the list) without opening the 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?

Gives clear usage context by naming real scenarios (deadlines, SLAs, delivery estimates) that motivate the addWorkingDays and range modes. However, it offers no when-not guidance, no mention of alternatives, and doesn't explain which parameter combination triggers which of the four listed operations.

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