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

Annotations already establish the read-only, closed-world, non-destructive profile, and the description adds real substance on top: what comes back (休み理由 and 祝日名), the extra previous/next business day output for single dates, and the fact that the closure rule set is configurable with a stated default of weekends plus holidays. It does not cover error behavior or input conflicts, but it clears the lower bar set by the annotations.

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?

Three sentences ordered from core output, to the single-day special case, to rule configuration — front-loaded and free of filler. It is dense but every clause carries information; only the rule enumeration in the last sentence borders on restating parameters.

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 9 optional parameters and no output schema, the description does necessary work by naming the returned fields and the next/previous business day output that an agent could not otherwise predict. It is not fully complete: it is silent on what happens if `date` and `start`/`end` are supplied together, and on any error/limit conditions beyond the 62-day cap.

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% and the schema already documents each date format, per-flag defaults, and the meaning of closed_weekdays/open_dates/closed_dates, so the description largely restates structured data. The one genuine addition is the 62-day maximum span, a constraint that is absent from the schema; the either/or relationship between `date` and `start`/`end` is only hinted at.

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 first sentence states a specific operation (business-day vs. holiday determination) with its scope boundary (a single date or a span up to 62 days) and its return semantics (reason and holiday name). An agent can distinguish it from siblings such as list_holidays or find_dates on the basis of this alone, although no sibling is named 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?

It distinguishes the one-day case (which additionally yields previous/next business day) from the range case, which is useful routing context, and states the default rule set. However, it never says when to prefer this tool over list_holidays or count_days, and gives no exclusion conditions; the usage guidance is implied rather than explicit.

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