육아 타임라인(임신 중·출산 후 기한·검진·예방접종·지원금·휴가 일정)

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

Annotations only declare read-only/idempotent/open-world; the description goes well beyond by disclosing that figures come from year-by-year tables, that post-birth items during pregnancy are computed off the due date, that minimum dose intervals and catch-up schedules are NOT modeled, that no API key is needed, and that LAW_OC triggers an optional external statute-revision check. It also discloses output traits per item (period, nature as statutory/obligatory/recommended/application/informational, progress state, source and verification status) and a reference-only disclaimer.

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 core computation is front-loaded in sentence one, and the long inclusion list does earn its place by defining scope for a tool with no output schema. It is dense, though — the enumeration of benefits, checkup counts and vaccine counts could be compressed, and the disclaimer plus LAW_OC note make it longer than strictly necessary.

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 8 all-optional parameters and no output schema, the description carries the burden well: it explains the two calculation modes, what each returned item contains, which real-world categories are in vs out of scope, and the data basis (yearly tables, optional statute lookup). An agent has enough to call it correctly and to describe the result to a user without further clarification.

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 interpretive meaning: it frames due_date and birth_date as an either/or mode switch and warns that region only affects the 'where to confirm' text, not date or amount calculation. The note that amounts/ages follow yearly tables and post-birth items during pregnancy are due-date-based changes how an agent should read the returned numbers rather than just param syntax.

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 concrete verb and resource: it computes a date-ordered schedule from either a due date (pregnancy) or a birth date (post-birth). The enumeration of what the timeline covers (birth registration deadline, parental benefit/child allowance windows, first-meeting voucher, leave types, 8 infant checkups + 4 oral checkups, 13 national immunizations) makes the scope unmistakable and implicitly separates it from the narrow lookup siblings like find_benefits or find_vaccination_clinic.

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 clearly establishes the triggering context (pregnancy vs post-birth) and which of due_date/birth_date selects each mode, which is real usage guidance. However, it never explicitly names a sibling or says when NOT to use this aggregating timeline (e.g. 'use find_local_support for region-specific programs'), so routing between this tool and the ten lookup tools is left to inference.

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