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

Goes well beyond the readOnly/idempotent annotations by disclosing the exact return shape (article text, 항, 호, separate law-level metadata) and the non-obvious nuance that an article's effective date can differ from the law's. It also surfaces the BYOK auth requirement and the `_apiKey` credential need, which annotations do not convey.

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?

Four dense sentences, front-loaded with the core scope constraint and the article_no mode switch before the return-value details. Every sentence carries distinct information; nothing is repeated from the name or title.

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 and their relationships, and it covers the credential requirement for a BYOK tool with five parameters. An agent has everything needed to call it correctly and interpret the response.

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 adds real semantic value: it explains the mode coupling that gives `page` and `display` meaning (they only apply to table-of-contents mode) and restates the `mst` provenance link to kr_law_search. The article_no numbering format is already in the schema, so no credit there.

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 ("Fetch ONE article (조문) of a South Korean statute") and immediately bounds scope with "Never returns the whole law body." It also anchors the required `mst` parameter's provenance to the sibling tool kr_law_search, so an agent can distinguish it from other law tools without inspecting 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?

Explicitly defines two modes: supply article_no for a single article, omit it for a paginated table of contents, and names kr_law_search as the source of `mst`. It stops short of stating when to prefer kr_law_history or what to do if the article number is unknown, so alternatives are only partially covered.

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