Factline Netherlands

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

Beyond the annotations it discloses the payment mechanics (secure link, iDEAL or card, via Dodo Payments, EUR 2.95 incl. VAT) and the delivery behavior (report opens right after payment). This is exactly the behavioral context an agent needs before triggering a paid transaction and is not derivable from the annotations.

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-loads the outcome (payment link) and price, then the report contents, then the usage condition. The enumerated content list is long but each item is informative; structure is sound with little wasted text.

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?

No output schema exists, but the description explains the return value (a secure payment link) and the post-payment behavior, covering the important gaps. It is nearly complete, though it does not clarify how the free-text q parameter relates to the structured postcode/house_number options.

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 address parameters (q, postcode, house_number, addition, house_letter) are already documented in the schema. The description adds only the phrase 'on a Dutch address' and no extra syntax or precedence detail beyond the schema baseline.

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 (buy) and resource (the full address report), and itemizes exactly what the paid report contains. It is clearly distinguishable from the free sibling tools like nl_home_report and nl_home_basic.

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?

'Only use when the user wants the full report or asks to buy it' is an explicit usage constraint and exclusion, which is strong. It does not, however, name the specific free alternative tools an agent should route to otherwise, so it stops short of full routing guidance.

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

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

Goes well beyond the readOnly/idempotent annotations: it discloses pricing (0.0015 USDC per address, 0.015 total), payment paths (x402 or Factline API key credits), the free-tier rule, and that unfound addresses are flagged and not charged. These are exactly the operational facts an agent needs before a paid call.

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 "Use when" and dense with useful facts; nearly every clause carries information. The final payment sentence is long and slightly run-on, but not wasteful.

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 compensates by enumerating the returned data fields (BAG address, coordinates, CBS neighbourhood, liveability, crime, home value, optional energy label) and handling of unfound addresses. Nothing an agent needs to call it correctly is 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 three parameters are already documented in the schema. The description reinforces the batch cap and mentions optional energy label content but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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 (enrich) and resource (a list of Dutch addresses), plus the batch cap of 10 per call. This clearly distinguishes it from single-address siblings like nl_address_lookup. An agent can select it without opening the schema.

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 enriching a list" gives a clear trigger, and the up-to-10 batch limit implies when to prefer it over the single-lookup sibling. However, it never names an alternative tool or states exclusions explicitly, so it falls short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real value beyond them: the upstream source (Kadaster BAG via PDOK), the exact price (0.002 USDC via x402 or 1 API credit), and the free-tier rule (first 5 paid-tool calls per day, no payment or key required). Pricing and auth expectations are exactly the kind of behavioral context annotations cannot express.

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 and the return payload before pricing details, and every sentence carries distinct information. Slightly dense at four clauses in one paragraph, but no filler.

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, yet the description enumerates the return fields (latitude/longitude, BAG ids, municipality, province, CBS neighbourhood code), and it covers cost, auth path and free tier. Nothing material for calling this paid geocoding tool correctly is 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 coverage is 100%, so the baseline is 3; the description earns an extra point by explaining the two mutually exclusive input modes ('postcode + house number or free text'), which is a semantic constraint the schema itself does not state since no fields are marked required or exclusive.

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 and resource ('check that a Dutch address exists or get its exact spelling and coordinates') and enumerates the returned BAG fields, so the operation is unmistakable. It does not, however, name or contrast itself with close siblings such as nl_address_reverse, nl_postcode_addresses or nl_address_batch, so an agent must infer the boundary.

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?

The opening clause gives an explicit trigger condition ('Use when you need to check that a Dutch address exists or get its exact spelling and coordinates') and the third sentence lists concrete scenarios (onboarding, delivery, CRM). No when-not-to-use or named alternative is given, which keeps it short of a 5.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, and the description adds real context on top: data source (Kadaster BAG via PDOK), dual pricing (0.002 USDC via x402 or 1 API-key credit), and the first-5-calls-a-day free allowance. Payment and auth mechanics are exactly the kind of behavioral fact annotations cannot convey.

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 triggering condition, then outputs, then input format, then cost. Four dense sentences, each carrying distinct information; nothing is redundant with the title or schema.

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?

No output schema exists, yet the description enumerates the returned fields and their meaning (distance in metres, administrative hierarchy, nearby addresses), so the agent knows exactly what to expect. Inputs, cost, auth and data provenance are all covered for a 3-parameter read 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 coverage is 100%, so the baseline is 3, but the description adds the datum (WGS84) and currency (degrees, with the examples 52.0836 / 4.2919), which is meaningfully beyond the schema's bare "Latitude" label. It also frames the api_key parameter through the credit-vs-x402 payment model.

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 operation (coordinates → nearest official BAG address) and enumerates the exact return payload: distance in metres, postcode, city, municipality, province, BAG ids, CBS buurt/wijk codes, plus neighbours. This is clearly distinguishable from address-lookup siblings such as nl_address_lookup or nl_postcode_addresses, which take the opposite direction of input.

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 you have coordinates in the Netherlands and need the address" gives a concrete triggering condition, and the payment note implies when the free tier is exhausted. It stops short of naming alternatives (e.g. nl_address_lookup for address→coordinates, nl_address_batch for bulk), so the agent must infer the routing itself.

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

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

Annotations already cover read-only, idempotent, open-world and non-destructive semantics, so the description does not need to repeat them. It instead adds genuinely useful operational context: the data source (Politie open data, CBS), the exact price (0.003 USDC via x402 or 2 credits), and the free allowance of five paid calls per day. It does not disclose coverage gaps or error behaviour when a postcode is unknown, which is the main remaining omission.

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 structure is well front-loaded: trigger condition first, then what is returned, then input, source and pricing. Roughly four sentences with little waste. The pricing sentence is the longest but carries non-recoverable information, so only minor trimming is possible.

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, so the description must convey the return shape, and it does: counts plus a ratio per 1,000 residents against the national rate across five crime categories. Combined with source attribution, input formats and payment mechanics, an agent has everything needed to decide to call and to interpret the result.

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 three parameters (code, postcode, api_key) are already documented with examples. The description's "Input: Dutch postcode or CBS buurt code" merely restates that, and does not clarify whether code and postcode are mutually exclusive or which takes precedence. Baseline 3 applies when the schema carries the parameter burden.

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 resource and metric: police-registered crime per 1,000 residents versus the national rate, broken out into burglary, bicycle theft, vehicle crime, violence and vandalism. That is far more concrete than a generic "get neighbourhood data" tool. It does not explicitly contrast with nearby siblings such as nl_neighbourhood or nl_neighbourhood_summary, so an agent must infer the boundary from the name alone.

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 a clear triggering condition: use when the user asks whether a Dutch neighbourhood or postcode is safe. That maps directly onto a foreseeable user intent. However, it never states when not to use it or which sibling to choose for broader neighbourhood statistics, so no explicit alternative routing is provided.

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

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

Beyond the annotations (readOnly/idempotent/non-destructive/openWorld), the description discloses the data source (RVO EP-Online national register), the payment model (0.005 USDC via x402 or 3 credits of a Factline API key), and a free-tier rule (first 5 paid-tool calls per day free). Payment and auth requirements are exactly the behavioral facts an agent must know before calling a paid tool.

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 use case, then input, then source, then cost — a logical order with no filler. The dual payment explanation is slightly long, but every clause carries information an agent needs; no sentence is pure repetition of the title.

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, and the description compensates by enumerating the returned fields including the negative case ('none registered'). Combined with the source, cost, and auth guidance, nothing an agent needs to call this correctly and set user expectations is 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 every parameter including the free-text 'q' alternative and api_key is already documented in the schema. The description only restates 'Input: postcode + house number', adding no syntax or fallback detail beyond what the schema provides. Baseline 3 applies.

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 and resource ('energy label of a Dutch home') and enumerates exactly what is returned: registered label A++++ to G, registration/expiry date, building type, energy index, or an explicit 'none registered'. That distinguishes it clearly from siblings like nl_home_basic or nl_home_report, which cover broader home data.

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?

The trigger is explicit ('Use when the user asks for the energy label of a Dutch home'), so an agent knows the exact user intent that selects this tool. It does not name a sibling alternative or an exclusion case, which keeps it short of a 5.

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

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

Beyond the read-only/idempotent annotations, it discloses data provenance (Rijkswaterstaat LIWO, AHN), supported climate scenarios, pricing (0.004 USDC or 2 credits), payment method (x402/API key), and a free daily quota. These are operationally important details an agent needs before calling a paid open-world tool.

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 trigger and key outputs, then moves efficiently to input, cost, and free-quota details. Every sentence contributes useful selection or invocation 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?

For a paid, open-world tool with no output schema, the description covers the trigger, returned metrics, data sources, climate scenarios, input types, pricing, payment methods, and free quota. An agent has enough context to decide whether and how to call it.

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 schema already documents the six parameters. The description only restates 'postcode + house number' and does not explain the alternative q field, api_key usage, or optional addition/house_letter parameters, so it adds little beyond the schema.

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 names a specific user question ('if a Dutch address can flood') and the exact resource returned: annual flood probability, climate scenarios, worst-case water depth, and ground height. This is clearly distinct from sibling address/home tools such as nl_home_basic or nl_crime.

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 a clear trigger: 'Use when the user asks if a Dutch address can flood.' It does not state when not to use it or name sibling alternatives, but the use context is unambiguous.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered; the description adds value beyond them by disclosing the data sources (BAG, CBS, Leefbaarometer), the language of results (English), and the cost profile ('Free'). It does not describe failure behavior for unknown addresses, which keeps it at 4.

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?

Three sentences, front-loaded with 'Free.' and then the trigger, then inputs, then sources. Every clause carries distinct information and nothing is repeated from the schema or annotations.

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 it does so by listing the fact categories and result language. Sources are cited for provenance. Minor gaps remain on pagination/not-found behavior, but for a read-only lookup it is close to complete.

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 coverage is 100% with per-field descriptions, so the baseline is 3. The description adds the non-obvious either/or semantics ('Accepts postcode + house number or free text'), clarifying that q and the postcode fields are alternative input modes rather than a combined requirement.

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 names the resource (Dutch address/home facts) and enumerates the concrete data points returned: year built, floor area, use, neighbourhood residents, average home value, liveability percentile. 'Free' and the 'basic' name implicitly separate it from paid siblings like buy_full_address_report and nl_home_report, but no sibling is named 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?

It gives a clear trigger ('Use when the user mentions a Dutch address or asks about a home in the Netherlands') and notes the free tier, which is the main selection axis against paid siblings. There are no explicit exclusions or named alternatives, so it stops short of a 5.

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

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

Annotations only declare readOnly/idempotent/openWorld; the description adds the material operational facts an agent needs: the cost (0.08 USDC via x402 or 40 credits of a Factline API key) and the free quota (first 5 paid calls per day need no payment or key). It also previews the response shape (best address per metric plus full report per address), which annotations cannot convey.

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 use condition, then output contents, then input format, then pricing — a sensible order with no filler. The metric enumeration is long but each item is informative; a slight trim would make it tighter.

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?

For a paid, no-output-schema tool, it covers trigger, inputs, cost, free tier, and what comes back, which is nearly everything an agent needs. Minor gaps remain around failure modes (invalid addresses, exceeding 5, missing key without free quota left).

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 coverage is 100%, so both parameters are already documented, and the description's 'addresses separated by ;' merely restates the schema. It does reinforce the 2–5 cardinality constraint, but adds no format or edge-case detail (e.g. what happens with a non-Dutch or invalid postcode) beyond the schema.

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 and resource ('Compare Dutch addresses') plus the exact scope: 2 to 5 addresses, side-by-side on a named list of metrics with a best-per-metric verdict. The comparison framing plus the 2–5 range distinguishes it from single-address siblings like nl_home_report or nl_address_lookup without needing to name them.

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 is choosing between 2 to 5 Dutch addresses' gives an explicit triggering condition, and the 2–5 bound implicitly excludes single-address and bulk use cases. It does not name the sibling to use instead for one address or for 6+ addresses, so the routing is implied rather than spelled out.

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

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.

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds the things they cannot: data provenance (CBS, Kadaster), an explicit price (0.003 USDC via x402 or 2 credits of a Factline API key), and a free tier (first 5 paid-tool calls a day, no payment or key). Payment and auth requirements are disclosed up front, which is exactly the extra burden a paid tool needs.

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-loads the trigger ('Use when...'), then the scope boundary, then input and cost. Four dense sentences with no filler; even the pricing detail earns its place because it changes whether an agent can call the tool at all.

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?

No output schema exists, and the description compensates by describing what comes back: neighbourhood WOZ with its trend, plus per-year municipal sale prices benchmarked against the national average. Combined with source attribution and full cost/auth details, an agent has everything needed to select and invoke it.

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 three parameters (postcode, code, api_key) are already documented with examples. The description's 'Input: postcode or CBS buurt code' restates what the schema says rather than adding format, fallback precedence, or validation rules. Baseline 3 applies.

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 resource (average WOZ home value for a Dutch neighbourhood plus yearly sale prices for the municipality vs national) and a specific verb-of-use ('asks what homes cost'). The line 'Context for an asking price, not a valuation of one home' separates it from valuation-style siblings like nl_home_report or nl_rent_check without opening any schema.

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?

The leading 'Use when the user asks what homes cost in a Dutch area' plus the explicit exclusion ('not a valuation of one home') gives both a trigger and a when-not. It stops short of naming the sibling tool an agent should pick instead for a single-home valuation, which keeps it from a 5.

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

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

Annotations already declare readOnly/idempotent/safe, and the description adds genuinely non-redundant context: pricing (0.01 USDC via x402 or 5 credits), a free tier of 5 paid calls per day with no key, the upstream data sources, and that results are in English. None of that is recoverable from the structured fields.

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 'Use when' trigger, then input, sources, and cost — a sensible priority order. Dense and largely waste-free, though the long amenity/crime enumeration makes the first sentence heavy.

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 carries the return-value burden and does so thoroughly by enumerating every metric class and the output language. Payment mechanics, free tier, and accepted input types are all covered, leaving nothing an agent needs before calling.

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 coverage is 100% and each parameter already carries its own example (postcode format, BU code format, api_key prefix). The description only restates that a postcode or buurt code is acceptable, adding no format, precedence, or edge-case guidance beyond the schema — baseline 3.

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?

Specific verb-plus-resource framing ('what a Dutch neighbourhood or postcode area is like') followed by an explicit content inventory: residents, age mix, housing, income, energy, amenities, crime, liveability. The one gap is that the clearly overlapping sibling nl_neighbourhood_summary is never mentioned, so the agent gets no explicit differentiation.

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 what a Dutch neighbourhood or postcode area is like' is a clear trigger condition, and 'Input: any postcode or CBS buurt code' scopes the accepted inputs. No when-not conditions and no named alternatives (e.g. nl_neighbourhood_summary, nl_crime, nl_house_prices) are offered.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-structured context: the tool is free, it aggregates from three named public sources, and it returns comparative figures (crime vs national rate, liveability percentile) rather than raw data. It does not discuss latency, coverage gaps, or what happens for an unknown postcode, which keeps it below a 5.

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 two pieces an agent needs first ('Free. Use when...') followed by one dense but well-ordered sentence listing the payload fields and sources. No filler sentences, though the enumerated output list runs long and could be tightened.

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, so the description must carry the return-value burden, and it does: it enumerates each headline metric and names the upstream sources. Combined with annotations covering read semantics, an agent has everything needed to call this correctly and describe the result to a user.

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 both parameters (postcode and optional CBS buurt code) are already documented with examples in the schema. The description only implies postcode-based input ('headline facts for a postcode') and adds nothing about the alternate code parameter, so the baseline 3 for high-coverage schemas applies.

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 resource (Dutch neighbourhood/postcode summary) and enumerates the exact headline facts returned: residents, WOZ home value, owner-occupied share, liveability percentile, crime per 1,000 vs national, and distances to amenities. The 'Free' marker and explicit data sources (CBS, Politie, Leefbaarometer) let an agent place it against siblings like nl_home_report and nl_crime without opening any schema.

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?

Gives a clear triggering condition: 'Use when the user asks what a Dutch neighbourhood or postcode area is like, or whether it is safe.' That is a strong when-to-use signal, but it names no alternative tool for adjacent needs (e.g. street-level lookups via nl_address_lookup or a single-topic nl_crime query), so the routing is implied rather than explicit.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world, so the description correctly spends its words elsewhere: dual pricing (0.005 USDC via x402 or 3 credits), the 5-free-calls-per-day quota, and the Kadaster BAG/PDOK provenance. That cost and free-tier context is exactly the kind of behavior annotations cannot express.

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, then output fields, use cases, source and cost. Three sentences, each earning its place; the pricing sentence is long but essential for a paid tool. Minor redundancy between the title and the opening clause.

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 compensates by listing the returned fields and sort order, and it covers payment/auth paths so the agent knows what to do without a key. It doesn't say whether all addresses for a postcode fit in one response or how large a postcode payload typically is.

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 coverage is 100% – both postcode format and the api_key flow are documented in the schema. The description adds no parameter syntax or constraints beyond that, so baseline 3 applies.

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 and resource ('every address in a Dutch postcode') and enumerates the returned fields (street, house number, letter, addition, BAG id, coordinates) plus ordering. This clearly separates it from single-address siblings like nl_address_lookup and nl_address_reverse without needing to name them.

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?

Explicit trigger ('Use when you need every address in a Dutch postcode') plus concrete use cases: address pickers, delivery/canvassing routes, data cleaning. It never states when NOT to use it or names the single-address/batch alternatives, so it stops short of a 5.

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

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

Annotations already declare read-only/idempotent/non-destructive, and the description goes well beyond them: pricing (0.01 USDC via x402 or 5 credits), the free tier (first 5 paid-tool calls/day, no payment or key), and the qualitative caveat that results are an estimate with a link to the official check. Those are exactly the facts an agent needs before deciding to spend money.

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 sentence and dense but non-redundant: segment thresholds, pricing, and free tier each earn their place. The final two sentences on payment could be tightened, but there is no filler.

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?

Even without an output schema, the description says what comes back (points, likely segment, max basic rent, official-check link) and what input drives it. For a paid, read-only estimator with full schema coverage, nothing an agent needs before invoking is 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 the schema already documents postcode, house_number, addition, house_letter, q and api_key in more detail than the description does. The description's "Input: postcode + house number" adds the primary pair but omits that q is a free-text alternative and that api_key is the credit-based auth path, so it adds little beyond, and slightly narrows, the schema.

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 verb+resource (estimated rent points / WWS) and enumerates the actual outputs: points from floor area, energy label and neighbourhood WOZ, segment thresholds (143/144-186/187+), and approximate max basic rent. No sibling tool (address, energy, crime, house prices) does rent-point calculation, so the boundary is unambiguous.

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 a tenant asks if their Dutch rent is too high or what the maximum rent is" gives a concrete triggering scenario, and "An estimate with a link to the official check" sets the accuracy boundary. It stops short of naming a sibling to use instead when the question is really about energy label or WOZ value alone, so no explicit alternatives or exclusions.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new context: it is free, and it names the upstream sources (DUO, Landelijk Register Kinderopvang), which tells the agent about data provenance and authority. No auth or rate-limit detail, but little is needed for a free read-only lookup.

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 "Free. Use when..." so the eligibility and trigger come first. The subsequent clause is a long enumeration of returned fields, which is dense but each item (distance, denomination, pass rates, places) earns its place given there is no output schema.

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 and a single required parameter, the description carries the burden of describing returns and does so exhaustively: school levels, per-school metrics, exam pass rates per track, plus childcare types and registered places. An agent knows exactly what it will get back.

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% and the schema itself documents the postcode format with examples (3511LX or 3511). The description adds no syntax or filtering semantics beyond that, so the baseline of 3 applies.

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 resource (primary/secondary schools, daycare, after-school care) tied to a specific input (Dutch postcode/address), and the school/childcare focus clearly separates it from siblings like nl_crime, nl_energy_label, or nl_house_prices.

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 schools near a Dutch address or postcode, or is moving with children" gives explicit trigger conditions. It does not name any alternative tool or state when not to use it, so it falls short of a 5.

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