영업일·공휴일·기한 날짜 계산

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

No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: it returns skipped non-business days with dates, weekdays, holiday names, and legal basis; it warns about missing/unverified holiday data via warnings; it explains the nuance that Labor Day (5/1) is not a public office holiday, causing divergence between civil law and notice-based business day calculations until 2027. It also warns that holiday laws change and gives a concrete example (2027-05-03 substitute holiday). This is rich behavioral context beyond a simple 'calculates business days' statement.

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?

The description is moderately sized but information-dense. It front-loads the core purpose in the first sentence, then provides critical usage warnings and behavioral details. The bullet points are well-structured. It loses one point because the warning about 2027 Labor Day is somewhat verbose and could be tightened, but every sentence earns its place by conveying important caveats.

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?

Given the tool's complexity (4 parameters, no output schema, no annotations), the description is quite complete. It explains what each parameter returns, warns about data limitations, and provides legal context. It doesn't explicitly describe the output format structure, but without an output schema, a brief note on return shape would help. However, the description does list the types of outputs (business day status, holiday name, deadline adjustment, skipped days list, legal basis, warnings), which is sufficient for an agent to understand what to expect.

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 baseline is 3. The description adds value by explaining the semantics of each parameter with examples: add_business_days for '이사회 의결일 + 상장 3영업일 / 비상장·공익법인 7영업일', add_calendar_days for '분기 종료 후 45일', count_business_days_to for '오늘부터 기한까지 남은 영업일'. It also clarifies that date alone returns business-day status and next business day. This goes beyond the schema's basic descriptions, though it doesn't add syntax details for the date format (already in schema pattern).

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 clearly states the tool computes Korean business days, holidays, and deadline adjustments, listing specific outputs (business day status, holiday name, deadline adjustment, N-business-day/N-calendar-day deadlines, remaining business day count). It distinguishes itself from sibling tools by being the only date-calculation tool among disclosure/search/audit tools.

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 description explicitly instructs when to use the tool: '기한·영업일·공휴일이 걸린 날짜 질문에는 반드시 이 도구를 호출하세요' (must call this tool for date questions involving deadlines, business days, holidays). It also warns that the model's own calendar knowledge is outdated, providing a clear directive to prefer this tool over internal knowledge. It does not name specific sibling alternatives, but the sibling list contains no other date-calculation tool, so the guidance is sufficient.

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