datetime.count_business_days

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

Annotations only declare readOnly/idempotent/openWorld=false; the description adds genuinely new behavioral facts: both endpoints are inclusive, Saturday/Sunday plus the holidays package's country calendar (default KR) are excluded, and two concrete error conditions (reversed range, range over 100000 days). It also discloses a limitation — there is no input to add ad-hoc temporary holidays — which prevents a wrong call.

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, front-loaded with the action and return type, then the exclusion rules, then the error/limitation clause. No filler, though the final clause packs error conditions and the missing-holiday-input note into one dense sentence.

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 3-param, read-only, idempotent computation with an output schema, the description covers everything an agent needs: input format, inclusivity, holiday policy and default, error guards, and the absence of a custom-holiday parameter. Return shape is handled by the output schema, so nothing material is missing.

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 0%, so the description must carry parameter meaning, and it does: start/end are YYYY-MM-DD and inclusive, and country selects the holidays-package calendar with a stated default of KR. All three parameters get semantics the schema alone does not provide.

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+resource ('영업일 수 count 를 정수로 센다') with the exact scope: between start and end, inclusive of both endpoints, excluding weekends and country holidays. This clearly separates it from datetime.add_business_days (which shifts a date) and datetime.day_count (which counts calendar days) without needing to open any schema.

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 defines the operating rules (inclusive endpoints, weekend/holiday exclusion, default KR) and error boundaries (end before start, span > 100000 days), which implicitly tells the agent when this tool fails. However, it never explicitly routes the agent away from sibling alternatives like datetime.day_count or datetime.add_business_days, nor states when to prefer another tool.

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