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

Annotations already declare readOnly, idempotent, openWorld, non-destructive, so the safety profile is covered. The description still adds non-obvious behavior: results are relevance-ranked and may include loosely related articles, which is exactly the caveat an agent needs before trusting output. It does not mention result count or pagination behavior beyond the schema's page param.

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?

Three sentences, front-loaded with purpose, then the language constraint, then the scope option and the verification advice. No filler; the bilingual parenthetical and example earn their space by preventing malformed queries.

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?

For a 3-parameter read-only search with no output schema, the description covers the input contract (Korean question, scope) and the critical downstream step (verify with get_article). It could say more about what the result set looks like, but the essential calling information is present.

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 baseline is 3. The description does add some meaning beyond the schema — the Korean-sentence requirement with an example, and the gloss that 행정규칙 covers 고시 and 훈령 — but leaves page/result-size behavior to the schema.

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 — finding Korean law articles from a natural-language question — and pins the method ('법제처 intelligent law search') plus the article-level granularity. It does not explicitly contrast with the sibling search_law (keyword search), so the differentiation is inferable rather than stated.

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 real usage conditions: the question must be a Korean sentence (with a worked example), and scope 행정규칙 selects administrative rules. It also prescribes the follow-up step 'check the text with get_article'. What is missing is an explicit statement of when to prefer this over search_law or search_case.

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