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

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the baseline is met; the description adds genuine semantics beyond them — Good Friday is treated as a normal working day, weekend holidays are not moved to Monday, and coverage is limited to exact 2026-2027 national statutory holidays. It omits nothing critical, though it could note behavior for out-of-range dates.

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 usage, then computation, examples, inputs, outputs, formula, and fallback in clearly labeled lines. Every section earns its place except the outputs enumeration and argument examples, which duplicate the output schema and input schema respectively.

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?

An output schema exists, so return values need not be explained, yet the description still confirms output fields and adds policy details (good_friday_policy, weekend_holiday_policy, calendar_scope) plus a REST fallback and docs link. For a one-parameter read-only calculator, nothing an agent needs to invoke it 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 description coverage is 100% for the single date parameter with its own format and examples, so the schema does the heavy lifting. The description's 'Inputs: date (date)' and examples merely restate the schema, but do confirm the argument shape. Baseline 3 is appropriate.

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+resource (check an Ireland date against the weekend baseline and exact national statutory holidays) and scopes the calendar precisely to 2026-2027 national statutory holidays. It is immediately distinguishable from the many country-specific check_*_working_day siblings and from the add_/count_ variants by stating it returns a single-date working-day result.

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 gives both the when ('Use this when you need an Ireland national statutory public-holiday result') and the when-not ('Do not use this when you need an employer, bank, school, sector, local or individually selected benefit day'), plus instruction to call directly rather than answer from memory. This goes beyond anything inferable from the name or schema.

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