어린이제품 리콜 이력 조회(제품안전정보센터 Open API)

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.