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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's added value is commercial and operational: 0.04 USDC via x402, or 20 credits of a Factline API key, plus the first five paid calls per day being free. That is exactly the kind of context annotations cannot carry, and the named upstream sources (Kadaster, CBS, Politie, RIVM, RVO) help set expectations about data provenance. It does not say what happens on payment failure or how long a report takes.

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?

Front-loaded with the trigger condition, then the payload, then input, sources and pricing — a sensible order with no filler sentences. The long comma-separated field inventory runs a little dense, but each item materially aids selection between report tiers.

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 must convey what comes back, and the field enumeration does that. Costs, payment paths, daily free quota and input shape are all covered. Gaps are minor: no indication of response format or report size, and no guidance on the api_key flow despite the schema referencing get_trial_key.

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 the baseline applies. The description only adds 'Input: postcode + house number', which is weaker than the schema itself — notably it omits the free-text 'q' alternative and the api_key parameter that the schema documents. It therefore adds no semantics beyond the structured fields.

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 concrete deliverable — a full English report on a specific Dutch home/address — and enumerates the data it contains (year built, energy label, crime, noise, air quality, amenities, income, home values). That is far more specific than a restatement of the name. It stops short of a 5 because it never disentangles itself from close siblings such as nl_home_basic and buy_full_address_report, which an agent must distinguish by itself.

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?

'Use when the user asks about a specific Dutch home or address before renting, buying or moving' gives a clear triggering condition and even the user intent behind it. It offers no exclusions or named alternatives (nl_home_basic for a cheap subset, nl_address_lookup for a plain lookup), so routing between overlapping siblings is left to inference.

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