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

Beyond the readOnly/openWorld annotations, the description discloses meaningful behavior: deterministic/no-AI execution, explicit omission of weekend-only holidays, the 1 pm early-close detail, observance/substitute rules, and the x402 USDC payment model with a free tier. This is exactly the kind of context annotations cannot carry.

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 the core 'what it lists' clause, then caveats, then pricing. Dense but every sentence carries information; the pricing/payment sentence is the only part that could be seen as tangential, though it is operationally relevant.

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 no output schema, the description does the work of describing return content (full closures, early closes, observance rules) and payment/auth requirements. It is complete enough to invoke correctly, though it never states the response shape (structured list vs. text) explicitly.

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 already 100%, so the baseline is 3, but the description adds value by naming the holiday families each calendar code denotes and restating the supported year range, which helps the agent map 'XNYS' or 'UK-ENG' to real semantics rather than guessing from the bare enum-less example.

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 gives a specific verb ('Lists') and resource ('closing days for one calendar and year') and enumerates exactly what the list contains per calendar family (NYSE full closures and 1 pm early closes, Fedwire/FedACH holidays, TARGET2, UK bank holidays). It does not name or contrast any sibling, but the resource is specific enough to distinguish it from the business-day-math siblings at a glance.

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 — call it to retrieve holiday/closing-day lists — and the 2000-2099 year bound is stated, but there is no explicit when-to-use vs. when-not guidance and no reference to the sibling tools (is_business_day, business_days_between) that an agent might weigh it against.

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