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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description adds genuinely useful behavior beyond them: the $0.002 price, the x402/USDC-on-Base payment mechanism, and the crucial fact that a call without payment_signature returns payment requirements rather than a result. It does not describe the shape of a successful (paid) response or any error/rate-limit behavior.

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?

Four tight sentences with the purpose front-loaded, followed by usage, pricing/payment, and a sample pointer. The '[Data utilities]' prefix is minor filler but nothing else is wasted.

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 should carry the return-value burden, and it only explains the unpaid response (payment requirements), not what a paid call yields (a date? a count? a holiday list?). For an 8-parameter tool with several distinct modes, that leaves the agent guessing at the result shape.

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 all 8 parameters including `add`, `until`, `weekend`, and `payment_signature`. The description adds no parameter-level detail beyond that (e.g. how `add` and `until` interact, or default weekend handling), so the baseline 3 applies.

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 and resource: compute a payment/delivery/legal deadline in business days for a given country, with the holiday dependency named. It stops short of mentioning the other capability implied by the title, listing a year's public holidays via the `year` parameter, so the scope is slightly narrower than the tool actually is.

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 a concrete when-to-use condition ('Use when a due date or notice period depends on local public holidays') and explains the payment handshake ('Returns the x402 payment requirements unless payment_signature is given'). No siblings overlap this function, so there are no alternatives to route between, but no explicit exclusions are offered either.

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