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

Annotations only cover the safety profile (readOnly/idempotent/non-destructive), and the description adds real behavioral disclosure beyond them: token-length routing (≥3 chars → FTS with AND + rank, 1–2 chars → LIKE with 회신 first), and a result-packing rule that matched tf·qc keep at least 3 slots (≤limit/3). It also discloses data quirks — org vs source semantics, rel_stds being HTML with data-std/data-id, qna_key pinning for empty/duplicate doc_number, and the legacy-era caveat.

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?

Sectioned with [Purpose]/[Usage]/[Response]/[Rules] and front-loaded with what it searches, which is appropriate for a dense tool. The [Response] block is heavy — field lists, HTML note, org-vs-source aside — but it is load-bearing because there is no output schema; a little of it borders on reference material rather than selection guidance.

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?

No output schema exists, and the description fully covers the return shape ({hits, results}, per-kind object fields, relevance ordering with quota) so an agent knows what comes back and where to go next. Combined with search-mode rules and the legacy-date caveat, nothing needed to call it 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?

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: query is whitespace-separated tokens whose length changes the search mode, and limit is a combined cap across 회신+TF+회의자료 with a reserved-slot quota behavior. It stops short of stating any default or bound changes beyond the schema's own text, so not a 5.

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 (전문검색 of 질의회신 + 정착지원TF·품질관리실장 회의자료 in one list), and the title/description pair makes clear it is the Q&A-side search versus search_materials/search_standards. It also scopes the domain ('issues the 기준서 alone cannot settle'), so an agent can distinguish it from the standard-text search siblings without opening either 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?

Provides two concrete query examples showing the keyword style and limit usage, plus explicit routing both inward (문단-linked 회신 → get_paragraph related_qnas) and outward (kind "qna" → get_qna, kind "tf"/"qc" → get_material). It also states an exclusion rule — tf·qc are 논의·회의 요약, never to be cited as 질의회신 — which is exactly the when-not guidance an agent needs.

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