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

Annotations already declare readOnly/idempotent/openWorld, and the description adds genuinely new context: an external API key (DATA_GO_KR_SERVICE_KEY) is a prerequisite, results are summarized rather than exhaustive, and the tool explicitly does not assess risk or suitability. It does not discuss rate limits, error behavior, or result ordering, which keeps it short of a 5.

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 payload, followed by search advice and then the safety/credential caveats. Efficient overall, with minor duplication of the ingredient-name advice that also lives in the 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 a two-parameter read-only lookup with no output schema, the description supplies the return field list, the credential prerequisite, the negative-result caveat, and the scope limit. An agent has everything needed to call it and to frame the result responsibly.

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 both drug_name and limit are fully documented in the schema itself. The description's ingredient-name recommendation restates what the drug_name schema description already says, adding no new meaning; baseline 3 applies.

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: lookup of MFDS DUR pregnancy-contraindication items by drug name, and enumerates the fields returned (item name, company, contraindicated ingredient, dosage form, contraindication text, notes, notification date). Nothing among the siblings (leave articles, timelines, daycare, clinics, benefits) overlaps, so the agent can route here unambiguously.

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?

Gives clear operative guidance: search by ingredient name because product names may not resolve, and consult a clinician rather than relying on the tool for a negative result. It does not name an alternative tool or an explicit when-not-to-use condition, but no sibling competes for this task.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, but the description adds real behavioral context beyond them: an external auth secret (SAFETYKOREA_AUTH_KEY) is required, results are summarized newest-announcement-date first, certification records are separated from recall records, and absence of a record is explicitly not a safety guarantee. It does not discuss rate limits, pagination or error behavior when the key is missing, so not a 5.

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 purpose and scope are front-loaded in the first clause, and the caveats and auth note follow logically. It is dense — the opening sentence is long and run-on — but every element (scope, output fields, ordering, limitations, auth requirement) carries information an agent needs.

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 no output schema, the description compensates by enumerating the returned fields (source category, product name, company, announcement date, reason, action) and their sort order, and it flags the external auth requirement. Minor gaps remain around failure behavior when the service key is absent and around the effect of the limit parameter, which keeps this from a 5.

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 schema already documents limit, product_name (partial-match, 2–50 chars) and include_certification. The description restates the partial-name matching and the optional KC certification lookup but adds no new syntax, defaults or edge-case meaning beyond the schema. Baseline 3 is appropriate.

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 names a specific verb (query/summarize) and a specific resource (domestic/overseas recall and safety-investigation records from the SafetyKorea Open API, filtered by partial product name), and it describes the exact output fields and ordering. An agent can tell immediately what this tool returns and that it is unrelated to the sibling tools (daycare, clinic, benefits lookups).

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 gives clear context (looking up recall history for a product by name, before purchase/use) and explicitly states what the tool does NOT decide — recall status or purchase eligibility — plus advises checking manufacturer/seller guidance when no record is found. It stops short of an explicit 'use this when…' trigger sentence, and no sibling is a true alternative, so a 4 rather than 5.

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

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses operational traits the schema cannot: the list is cached for one day, region matching is an approximation derived from agency names, an external auth key (DATA_GO_KR_SERVICE_KEY) is required, and no application is performed. These are exactly the caveats an agent needs to avoid misreporting freshness or region precision.

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?

Four dense but purposeful sentences: purpose and output fields first, then caching/region caveats, then verification guidance, then the non-transactional disclaimer and auth requirement. Nothing is filler, though the parenthetical field enumerations make the opening sentence long.

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 no output schema, the description still enumerates the returned fields (서비스명·분야·대상·요약·신청처 with a detail link), and it covers caching, precision limits, auth prerequisites, and legal disclaimers. For a read-only four-parameter lookup tool, an agent has everything needed to call and interpret it correctly.

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 meaning not present in the schema: region filtering is approximate and based on agency name, and the tool's output is a summary rather than the full record. This contextualizes how much trust to place in the region parameter, though stage/limit/keyword semantics are largely restated from the schema.

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 names a specific verb (select/summarize) and a specific resource (행정안전부 공공서비스 혜택 목록, 보조금24) scoped to 임신·출산·영유아. It goes further by listing the exact filter axes (생애 단계·키워드·지역) and the returned fields, so an agent can distinguish it from data-retrieval siblings at a glance.

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 frames the tool as a reference lookup that does not process applications and tells the agent to confirm 자격·금액·신청 기간 via the detail link or the responsible agency. What is missing is an explicit comparison to overlapping siblings such as find_local_support, so the agent must infer that this tool covers pregnancy/childbirth/infant benefits rather than general local support.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses the auth requirement (DATA_GO_KR_SERVICE_KEY), the exact degradation behavior when the key is missing or the lookup fails (guidance only, no institution list), the fields returned (name, category, address, phone), and the boundary of what it will not answer. This is the kind of operational context annotations cannot carry.

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 capability is front-loaded in the first sentence and the caveats follow in a logical order. It is on the long side and the closing '키 없이도 쓸 수 있습니다' partly repeats the earlier no-key fallback sentence, a small redundancy.

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?

There is no output schema, so the description must describe return content, and it does: institution list fields plus fixed guidance on menu path, contacts, preparation, and current/next checkup rounds. With all parameters optional, it also covers the no-argument path and the keyless path, leaving nothing an agent needs 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 coverage is 100%, so all four parameters are already documented with formats and examples. The description restates that region drives the lookup and dates drive round calculation, and echoes the birth_date/due_date mutual exclusion already in the schema, adding little beyond it. Baseline 3 applies when the schema does the heavy lifting.

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 states a concrete verb and resource: finding infant/toddler health-checkup institutions by region and the child's birth date (or due date), plus supplementary guidance. It is not tautological and adds scope limits ('예약 가능 여부나 검진 결과는 알려주지 않으며'). It stops short of naming or contrasting sibling tools such as find_vaccination_clinic or find_night_pediatric, so an agent must infer the boundary itself.

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?

Usage context is clear: supply a region plus birth_date or due_date for a lookup, or run without them for general guidance, and it works even without the API key (degrading to guidance-only). Explicit exclusions (no reservations, no results) help the agent avoid misrouting. The gap is that no alternative sibling tool is named for adjacent needs like vaccination or night pediatric clinics.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is largely covered. The description adds genuinely new context beyond that: it performs no external lookup, returns only links and general guidance, omits capacity/cost/waiting-rank data, and requires no API key. The one gap is that it does not say how fresh or authoritative the linked pages are, but that is minor for a pure guidance tool.

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 that are front-loaded: purpose first, then limitations, then the no-API-key note. Each sentence carries distinct information, though the final API-key sentence is a minor extra for an already read-only, keyless-looking tool.

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 4-optional-parameter, annotation-covered tool with no output schema, the description tells the agent what it returns (links and general guidance) and what it will not return, which is the key completeness concern. It stops short of describing the shape or granularity of the guidance text, but that is a small residual gap.

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% and each parameter already documents format, examples, defaults (today = Korean time), and the birth_date/due_date mutual exclusion. The description only echoes that the guidance is keyed to region and birth/due date, adding essentially no semantics beyond the schema, so the baseline 3 applies.

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 names a specific action and resource: it returns daycare search and 입소대기 application page links plus regional selection steps, type-specific check items, and waiting-list procedure, keyed to region and birth/due date. It also states a negative scope explicitly ("외부 데이터를 조회하지 않아 정원·현원·대기 순번·비용 정보는 알려주지 않으며"), which makes it easy to distinguish from sibling lookup-style tools such as find_kindergarten or find_local_support.

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 indicates the context of use: when a user has a region and a child's birth date or due date and needs the application link and procedure guidance. It also rules out use for capacity, enrollment count, waiting rank, or cost questions, which is useful exclusion guidance. What is missing is an explicit pointer to an alternative tool for those excluded data needs.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered; the description adds genuinely new behavior — an external OpenAPI dependency requiring KINDERGARTEN_API_KEY authentication, real-time fetching, and the epistemic caveat that 여석 is an estimate rather than live data. It does not mention rate limits or failure modes, which keeps it below a 5.

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?

Two sentences, front-loaded with the data source and returned fields, then the estimate caveat and auth requirement. It is dense but each clause carries information; the returned-field enumeration is long, though justified 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?

With no output schema, the description compensates by enumerating the returned fields, and it also covers the estimate caveat, the non-enrollment scope boundary and the required API key. An agent has everything needed to decide to call it and to interpret the results correctly.

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%, and the schema already explains the age sorting behavior, the 1–30 limit with default 10, the 시군구-level region format and the partial-match establish filter. The description adds no syntax or semantics beyond that, so the baseline 3 applies.

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 names a specific verb and resource: real-time lookup of 유치원알리미 general-status disclosure data at 시군구 level, returning per-kindergarten 설립유형·주소·전화·공시 차수 and age 3/4/5 정원·현원·학급수 plus estimated vacancies. That is concrete enough to separate it from sibling find_daycare and from the clinic/benefit finders without opening the 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 makes the use case clear (checking capacity/vacancy estimates by district) and adds exclusions — vacancies are disclosure-based estimates, so real-time recruitment/waiting status and admissions must be confirmed with the kindergarten, and the tool does not act as an enrollment agent. It stops short of naming an alternative tool for those needs, so it is clear context rather than a full when/when-not routing rule.

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

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

The annotations already declare that the tool is read-only, idempotent, and open-world, so the description does not repeat them. Instead, it adds real operational context: it discloses the upstream data source, warns that information is 참고용 and that conditions and amounts must be verified with the relevant 지자체, and states the prerequisite API key (DATA_GO_KR_SERVICE_KEY) and dataset approval (15108347) needed before calling it. It does not describe pagination or failure behavior for an unapproved key, so this falls short of a 5.

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 capability is front-loaded in the first sentence, followed by the returned fields, the accuracy disclaimer, and the prerequisites; each sentence carries information. The wording is slightly dense but free of filler.

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 four-parameter, read-only search tool with no output schema, the description covers the data source, the returned fields, the accuracy caveat, and the credential/dataset prerequisites. The remaining gap is sibling routing against find_benefits and find_daycare, which is the only thing an agent might still get wrong.

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%: region, stage, keyword, and limit are already fully documented with format and examples in the schema. The description adds no parameter-specific meaning beyond restating the region and stage scope, so the baseline of 3 applies.

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 gives a specific verb and resource: it searches 임신·출산·영유아 지원 서비스 for a given 시도/시군구 from the 지자체복지서비스 dataset, and it lists the returned fields (서비스명, 소관 부서, 수정일, 원문 요약, 복지로 링크). It does not, however, distinguish this tool from similarly-named siblings such as find_benefits or find_daycare, so an agent may still hesitate over which one to call for a childcare/welfare query.

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?

Usage context is implied (finding local childcare support services by region and stage), and a caveat tells the user to confirm eligibility and amounts with the local government. There is no explicit statement of when to prefer this over find_benefits or find_daycare, and no guidance on exclusions or on when results may be empty.

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

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

The annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: a required DATA_GO_KR_SERVICE_KEY, a three-way open/closed/unknown judgment (확인 불가), and the ordering rule of currently-open, moonlight, then pediatric by name. However, nothing is said about rate limits, failures when the key is missing, or result truncation, so it is good rather than exhaustive.

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 most important facts are front-loaded: what is retrieved, how openness is judged, what gets returned, and the API key requirement, followed by short safety caveats. The first sentence is very long and heavily nested with parentheticals, which slightly hurts skimmability.

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?

There is no output schema, but the description compensates by listing the returned fields (name, type, address, phone, hours), the ordering, and the open/closed/unknown judgment categories. Combined with the prerequisite API key and the safety disclaimer, an agent has everything needed to call it and interpret the result.

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 schema already documents region, now, and limit formats, and the baseline would be 3. The description earns the extra point by tying `now` to a concrete semantic: the open/closed judgment uses today's weekday or holiday operating hours at that reference time, which the schema does not spell out.

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 states a specific verb and resource set: retrieve moonlight children's hospital and pediatric clinic lists from NMC public data, judge whether each is currently open based on today's weekday or holiday hours, and summarize the top facilities. This is clearly distinguishable from siblings such as find_vaccination_clinic or find_checkup_clinic, whose scope is different services rather than night/holiday pediatric care.

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 gives explicit exclusions and boundaries: emergencies should go to 119 or an ER, and it is a reference tool that does not diagnose or recommend hospitals. What is missing is a direct statement of when to prefer this over the adjacent clinic-finder siblings, so the routing guidance is implied by scope rather than stated.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that — no API key required, no live data query, and guidance is based on standard schedule data — but it does not describe how the link or contact information is structured in the response.

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 capability is front-loaded in the first sentence, followed by the important negative scope and the no-API-key note. It is a single dense paragraph that runs slightly long, but every clause carries information an agent needs.

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 four optional parameters, no output schema, and annotations covering the safety profile, the description does the necessary work by enumerating what the tool returns (link, selection steps, contacts, pre-visit checklist, current/next dose) and what it does not. Only the exact shape of the returned guidance is left unspecified.

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 formats, examples, and the due_date/birth_date mutual exclusion are already documented in the schema. The description restates the region and birth-date/due-date intent in prose but adds no syntax or edge-case detail beyond the structured fields, so the baseline 3 applies.

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 names a specific resource (national vaccination consignment clinics) and explicitly clarifies that it returns a screen link, selection procedure, contacts, and schedule-based dose guidance rather than performing a lookup. This directly counters the misleading 'find_' verb in the name and separates it from siblings like find_checkup_clinic or find_night_pediatric.

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 states the input context (region plus birth date or due date) and an explicit exclusion: no institution list, stock, or reservation availability is provided. However, it does not name an alternative tool an agent should call when it actually needs clinic data, leaving that routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered; the description adds genuinely new behavioral facts: an external open API is called, a LAW_OC credential is required, and output is advisory-only rather than authoritative legal advice. It does not discuss rate limits, failure modes, or how a missing/invalid LAW_OC surfaces, which keeps it below a 5.

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 scope and returned fields are front-loaded in the first sentence, with the credential requirement and the advisory disclaimer following in short, separate sentences. The first sentence is long due to the parenthetical field list, but every element earns its place and nothing is repeated.

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 one-parameter, read-only lookup with no output schema, the description covers the source system, the exact fields returned, the required credential, and the advisory-only limitation. An agent has everything needed to decide to call it and to interpret what comes back.

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% and the single enum parameter already spells out each value with its governing statute (남녀고용평등법 vs 근로기준법). The description only restates the same three leave categories, adding no mapping, default, or format detail beyond the schema, so the baseline of 3 applies.

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?

Names a specific verb (조회) and a specific resource (배우자 출산휴가·출산전후휴가·육아휴직의 근거 법 조문), and enumerates the returned fields (법령명, 조 번호와 제목, 항·호 내용, 공포·시행일). It also names the upstream source (법제처 국가법령정보 Open API), which no sibling tool touches — the other ten siblings are all lookup tools for childcare, benefits, clinics, and drugs.

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 scope of use is clear from the enumerated leave types and the stated source, so an agent knows to call this when a legal basis for leave is needed. It also sets an explicit exclusion — no legal interpretation or legal advice, results are reference-only. It stops short of naming an alternative tool or stating when NOT to call it in a routing sense, but no sibling overlaps this domain.

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

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.