야간·휴일 소아 진료기관 찾기(국립중앙의료원 공공데이터)

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.