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

Annotations already declare this as a read-only, idempotent, non-destructive, open-world tool. The description adds important context beyond that: it is a paid call costing 0.01 USDC via x402 or 5 credits of a Factline API key, with the first five paid-tool calls per day free. It also notes the estimate links to the official check, though it does not describe latency or accuracy limits.

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?

The description is front-loaded with the usage trigger and output summary, followed by input shape, pricing and free-tier details. Every sentence carries useful information, although the pricing sentence is somewhat dense and could be split for easier scanning.

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?

There is no output schema, but the description explains what the caller gets back: estimated rent points, likely segment under the 143/144-186/187+ thresholds, approximate maximum basic rent for 2026, and a link to the official check. Combined with the access-cost information, this is nearly complete for deciding to call it; only precision caveats and the alternative free-text input path are missing.

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 all five parameters are already documented. The description says 'Input: postcode + house number', which conveys the primary input path but omits the free-text 'q' alternative and the optional addition/house_letter fields present in the schema. Baseline 3 is appropriate because the schema does the parameter-level work.

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: estimated rent points (WWS) for a Dutch home, derived from floor area, energy label and neighbourhood WOZ. It clearly distinguishes itself from neighbouring address and energy-label tools by naming the WWS points, segment bands and 2026 maximum basic rent outputs.

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 an explicit trigger: 'Use when a tenant asks if their Dutch rent is too high or what the maximum rent is'. It does not name a sibling tool to use instead for related questions (for example nl_energy_label for the underlying label), but the intended scenario is unambiguous.

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