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

Annotations cover readOnlyHint=true and openWorldHint=true, so the safety profile is already declared. The description adds genuinely non-structured behavioral context: the upstream source, the returned fields (article number, effective date, source link), and critically the paid-call model ($0.005 USDC via x402 on Base), which an agent must know before invoking.

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 sentences, front-loaded with the core capability and return shape, ending with the cost/mechanism. No filler; every clause carries information.

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 pre-announces the return contents and the payment requirement, which is enough for an agent to call it. But the parameters — especially the two undocumented optional ones — leave a real gap for a 3-parameter 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% and none of the three parameters are documented anywhere. The description never explains the optional `no` and `law` parameters, leaving the agent to guess whether they pre-scope the search or are required for certain queries; only the implicit 'ask' maps to `question`.

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+resource: natural-language lookup of a Korean statute returning the matching law and article text, with the source named (National Law Information Center). It does not, however, distinguish itself from the sibling kr_law_article, so an agent cannot tell from the description alone whether to query by question or by article reference.

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 only implied — 'ask about a Korean statute in Korean or English' tells the agent the input style but gives no when-to-use/when-not guidance and never names kr_law_article as the alternative for direct article retrieval. With a near-identical sibling present, explicit routing would have been valuable.

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