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

The description adds significant behavior beyond annotations: it discloses that only crawl_status='ok' standards are listed and that an absent standard means '미수집' (not collected), not 'exists nowhere' — a crucial completeness caveat. It also documents that category is a free-form string where an unknown value yields count=0 rather than an error, plus the full response shape. All of this is consistent with readOnlyHint=true and idempotentHint=true; the openWorldHint=false annotation is not contradicted because the description clarifies exactly what absence means rather than asserting standard AI completeness semantics.

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 longer than average but every section earns its place: [Purpose], [Usage], [Response], [Rules] each carry distinct, non-redundant information. The core purpose is front-loaded in the first sentence, and the rules section condenses two subtle behavioral traps (crawl-status semantics, free-form category) into one compact block.

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 one optional parameter, annotations that already cover safety/idempotency, and no output schema, the description covers everything needed: response shape ({count, standards:[{std_num,title,category}]}), all category values, error semantics, completeness semantics, and sibling routing. Nothing an agent needs to call this tool correctly is 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?

Even though schema coverage is 100%, the description goes far beyond the schema's terse '카테고리로 필터 (생략 시 전체)' by enumerating all eight accepted category values (kifrs, interpretation, concept, kgaap, audit, icfr, esg, translation, special) and the count=0-not-error behavior. Usage examples tie Korean phrasings to parameter values, which the schema alone does not provide.

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 opening line states a specific verb and resource: '수록된 기준서 카탈로그를 반환합니다' (returns the catalog of included standards). The embedded question 'Which 기준서 are in the corpus, and which numbers feed search_standards' std_num filter' explicitly positions it as the catalog feeder to the search sibling, making differentiation immediate.

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 Usage section maps natural-language intents to concrete invocations ('감사기준서만' → category="audit", '내부회계관리제도 관련' → category="icfr"), which is actionable guidance an agent can follow directly. The purpose statement names search_standards as the consumer of its output, clearly separating catalog enumeration from content search.

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