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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it uses a pinned snapshot of the official GOV.UK bank-holiday feed, it computes based on a specific formula (bank holiday → non-working, weekend → non-working, else working), and it returns a status_basis and source_url. It also discloses the date-range constraint (2024-2028) and the division-specific behavior. It doesn't describe pagination or error behavior, but for a read-only calculator that's not a significant gap.

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 well-structured with clear sections: when to use, when not to use, what it computes, example requests, inputs, outputs, formula, and REST fallback. It's longer than average, but every section earns its place by providing actionable guidance. The front-loaded 'Use this when' sentence is the most important information and appears first.

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 read-only calculator with a rich output schema, the description is complete. It covers the date range, division semantics, the formula, the output fields, the REST fallback, and documentation link. An agent has everything needed to select and invoke this tool correctly, including how to handle the substitute holiday example.

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%, so the schema already documents both parameters well. The description adds meaning by explaining the division enum values ('England and Wales share one official list; Scotland and Northern Ireland have separate lists') and by giving complete JSON argument examples. It also clarifies the date format and range. This goes beyond the schema's basic 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 states a specific verb ('check'), a specific resource (UK working day), and the exact scope (2024-2028, Monday-Friday after official bank holidays for the selected division). It also distinguishes itself from sibling tools like check_china_working_day and count_uk_working_days by naming the division-specific behavior and the pinned GOV.UK feed.

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 explicitly says when to use this tool ('Use this when you need to know whether a 2024-2028 UK date is a Monday-Friday working day...'), and explicitly says when not to use it ('Do not use this when you need a local council, school, employer, financial-market, emergency-closure or non-UK calendar, or a date outside 2024-2028'). It also provides example user requests and a direct REST fallback, which is strong routing guidance.

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