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

Annotations already cover the read-only and open-world profile. The description adds genuinely new behavioral context: the data provenance (National Law Information Center) and, critically, the paid-call model ($0.005 USDC per call via x402 on Base). Knowing a call costs money is material to invocation decisions and is not captured by any structured field.

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?

Two compact sentences, front-loaded with purpose and followed by provenance and pricing. No filler, no repetition of the tool name, and each clause contributes an actionable fact.

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 usefully states that the return is the official article text, and it covers cost and source. It does not address failure modes (unknown law name, out-of-range article number) or response shaping, which would be the remaining pieces for a paid lookup tool.

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 0%, so the description must carry the load. It does clarify the 'law' parameter by enumerating accepted forms (Korean, common abbreviation, or English), which is real added meaning. However, the 'no' parameter is only described as 'article number' with no format guidance (e.g., '3' vs. '제3조'), leaving a real gap at 0% coverage.

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 gives a specific verb+resource: retrieving the official text of ONE article of a Korean statute, with named inputs (law name, article number) and an authoritative source (National Law Information Center). This makes the single-article scope clear enough to distinguish it from the sibling kr_law_query (search-style) without opening a schema, though it never names that sibling explicitly.

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?

Usage is implied by 'one article of a Korean statute by law name and article number' – an agent can infer this is for precise single-article citation rather than searching. However, there is no explicit when-to-use statement, no mention of the kr_law_query alternative, and no guidance on what to do if the article is not found.

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