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

Annotations cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely non-derived context: the data source (MOLIT real-transaction register) and the per-call price of $0.005 USDC via x402 on Base. Cost and payment mechanism are exactly the kind of behavioral detail annotations cannot express, though rate limits and pagination are unaddressed.

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 data resource and scope before the pricing note. No wasted words; the payment sentence is justified by the tool's paid nature.

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?

The description usefully enumerates the returned metrics and the data source, which partially compensates for the missing output schema, and it discloses cost. But with 0% schema description coverage an agent still lacks the region/apt identifier formats needed to call it correctly.

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 parameter meaning. It does map the params conceptually — region as a district, apt as a complex, months as a lookback window — but gives no format or identifier conventions for region/apt and does not explain why months is typed as a string.

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?

Names a specific resource and metric set: monthly trade count, median price, and median price per m2 for one Korean district or complex, sourced from the MOLIT register. An agent can tell what data it returns, though it never explicitly distinguishes itself from the sibling kr_apartment_query.

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?

There is no when-to-use guidance. With a close sibling (kr_apartment_query) in the tool list, the description should say when this trend tool is preferable to the point-query tool, but it offers nothing.

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