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

The description adds substantial behavior beyond the readOnly/idempotent/destructive annotations: tokenization rules (≥3 chars → FTS AND + rank, 1~2 chars → LIKE), empty-query error behavior, the fact that source indicates DB generation not 회신 기관, and that rel_stds is raw HTML requiring tag stripping and data-attribute parsing. No contradiction with annotations exists.

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 typical, but every section earns its place given the tool's subtle field semantics (source vs org, raw HTML in rel_stds) that would otherwise mislead agents. Purpose is front-loaded and the [Purpose]/[Usage]/[Response]/[Rules] structure makes the density navigable.

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 carries the full burden of explaining return values, and it does: the response shape is given, each non-obvious field (source, org, rel_stds) is clarified, the empty-query error case is documented, and the tokenization contract is specified. Nothing an agent needs to call this 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. The description goes beyond the schema by showing how to convert natural-language requests into effective queries ('전환사채 콜옵션 회계처리 질의회신' → query='전환사채 콜옵션'), demonstrating limit usage, and explaining query tokenization semantics. Concrete examples add real meaning the schema alone lacks.

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 specific verb (전문검색/full-text search) and a precise resource (3,669건의 질의회신 from four named authorities). It also differentiates from the sibling get_paragraph by noting that related_qnas is more precise for paragraph-specific 회신, so an agent can select correctly without opening schemas.

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 [Purpose] section states when to use this tool ('practice issues the 기준서 text alone cannot settle') and explicitly names the alternative (get_paragraph's related_qnas) with the condition that selects it. The [Usage] section gives two concrete query-building examples with exact parameter values, leaving nothing to inference.

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