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

With no annotations, the description carries the full disclosure burden and does most of it: it names the counting rule (working days, weekends skipped), the holiday source (national public holidays by country), the billing cost ($0.001 USDC per call via x402), and shows a concrete return payload. It omits what happens when country is omitted and does not explain the 'inclusive' flag that appears in the example but not in the schema.

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 action, then use cases, then computation rules, then cost, then a sample return value — no sentence is redundant. The example payload is doing useful work given there is no output schema.

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 an unannotated, no-output-schema tool the description supplies the computation semantics, pricing, and a return-value example, which covers most of what an agent needs. The remaining gap is the undocumented default when country is absent and the unexplained 'inclusive' field, which hints at a counting behavior (whether end date counts) the agent cannot confirm.

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 real meaning by tying the country parameter to a behavior — which national public holiday calendar gets excluded. It does not add format detail beyond the schema's YYYY-MM-DD and ISO 3166 alpha-2 notes.

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 ('Calculate business days between two dates') plus concrete use cases (SLA, invoice due dates, shipping, legal deadlines) that let an agent match it to a task. The 'between two dates' phrasing also implicitly separates it from a day-adding operation like the sibling business_day_add, though it never names an alternative explicitly.

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 enumerated scenarios (SLAs, invoice due dates, shipping and legal deadlines) give clear positive guidance on when to reach for this tool. There are no exclusions or named alternatives, and the relationship to public_holidays / business_day_add is left for the agent to infer.

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