Factline

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

Annotations already declare readOnly, idempotent and openWorld, but the description goes well beyond them: it discloses the cost model and payment path (0.002 USDC via x402 or 1 Factline credit), the caching behavior for domain lookups, and the exact output taxonomy (deliverable / risky / undeliverable). This is exactly the class of pre-purchase behavior an agent needs before invoking 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?

The check inventory is front-loaded and every clause carries distinct information (syntax, DNS, disposable lists, role addresses, typo suggestions, SPF/DMARC). The first sentence is long and list-like, but nothing is padding and the pricing sentence is short and load-bearing.

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 takes on the return-value burden and does so by naming the single verdict and its three values. Combined with cost, caching and the full check list, an agent has everything needed to decide and call 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?

Only one parameter and schema coverage is 100%, including an example address, so the schema already carries the parameter burden. The description adds no input-side semantics such as normalization or batching behavior; the typo example (gmial.com to gmail.com) describes output, not input.

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 (email verification and validation) and enumerates exactly what is checked: RFC syntax, live DNS/MX routing, disposable domains, role addresses, free providers, typo suggestions, SPF/DMARC. This clearly separates it from siblings like phone_verify and eu_vat_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?

Names concrete applicability contexts (signup, CRM, lead and outreach agents), which tells the agent when this tool fits. It does not name an alternative or state any exclusion (e.g. when not to verify, or that phone_verify covers the phone analogue), so it stops short of explicit 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description adds genuinely useful context beyond them: per-name pricing, the underlying lists and their weekly refresh cadence, fuzzy-matching behavior for spelling/word-order variants, and the payment/auth routes (x402 USDC or a Factline API key). This is exactly the kind of operational disclosure the annotations cannot carry.

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?

A single dense paragraph but well front-loaded: purpose and scope lead, then matching behavior, then use cases and cost. Every sentence contributes information (lists, matching, output shape, price); it is tightly packed rather than padded, though the nesting of cost details slightly crowds the flow.

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 describes the return shape (per name: possible match flag, top score, up to 3 scored matches with their lists). Combined with payment details, list sources and refresh cadence, it is nearly complete; only the 'type' parameter's effect remains under-specified.

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 50%: 'names' is documented in the schema (1-25, ';'-separated) and the description mostly repeats the 25-name cap. It does add the person/organisation distinction that maps to the undocumented enum 'type' parameter, giving it partial meaning, but the enum itself is never named or explained. 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 (screen) and resource (EU/UN/UK/US OFAC sanctions lists) with explicit scope: batch, up to 25 names per call. The 'batch' framing and the 25-name limit distinguish it from the single-name sibling eu_sanctions_screen without the agent needing to open either 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 clear usage contexts (customer onboarding, payouts, vendor/payment screening agents), so the agent knows the scenarios it serves. It does not, however, explicitly say when to prefer this over the singular eu_sanctions_screen sibling or note any exclusions, so routing between the two is left to inference from the name.

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/openWorld/idempotent annotations: it discloses fuzzy-matching behavior (spelling variants, transliteration, word order), return shape (scored matches with memberships, references, programmes, birth dates), data freshness (weekly refresh, 25,000+ entities), and cost (0.005 USDC via x402 or 3 credits). This is exactly the extra context an agent 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-loaded with the core action and coverage, then matching behavior, then returns, then pricing. Every clause carries distinct information with no redundancy.

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 describing the return content, and it also covers input scope, pricing, and refresh cadence. An agent has everything required to invoke and interpret this tool 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 67%, so the schema already documents name and birth_year. The description adds meaning to the name input via fuzzy-matching/transliteration notes, but says nothing about the 'type' enum (person/entity) or the birth_year format, leaving the enum parameter to the schema alone.

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 (screen) and resource (person or company name) with explicit scope: EU, UN, UK and US OFAC SDN lists in one call. This clearly distinguishes it from siblings like eu_sanctions_batch and eu_sanctions_wallet without needing to open their schemas.

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?

Names intended scenarios ('For onboarding, payments and due-diligence agents'), giving clear context for when this single-name screen applies. It does not, however, explicitly route to alternatives such as eu_sanctions_batch for bulk screening, so it stops short of full when-to-use/when-not 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/openWorld/idempotent annotations by disclosing the data refresh cadence (weekly), the exact cost and payment path (0.003 USDC via x402 or 2 credits of a Factline API key), and the response contents. An agent knows the safety profile, the freshness of the data, and the billing implications 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?

Three dense sentences with the core purpose and data source front-loaded, and no filler. The chain enumeration and pricing details are packed closely but each clause carries information the agent needs, so it reads efficiently rather than padded.

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 stating exactly what is returned (sanctioned true/false, currency, listed entity, programme). Combined with cost, freshness, and supported chains, everything needed to call and interpret the tool is present.

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 the schema supplies an EVM example, so the baseline is 3. The description adds meaningful value by enumerating the supported chains/asset types (Bitcoin, Ethereum/EVM, Tron, USDT, Litecoin, Monero), telling the agent which address formats are accepted beyond the single 0x example.

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 (screen/check) and resource (crypto wallet address) and names the exact data source (US OFAC SDN list). It also resolves the naming mismatch with its eu_sanctions_* siblings by making clear this screens the OFAC list, not an EU list, so an agent can pick it correctly.

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?

Explicitly names the scenarios that select this tool ('wallets, exchanges, payout, crypto onboarding and agent payment flows: screen a counterparty before sending funds'). It gives clear context but does not state when NOT to use it or point to the sibling alternatives like eu_sanctions_screen for non-wallet screening.

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 cover only readOnly/idempotent/openWorld; the description adds substantial behavior: results are cached for a day, a format pre-check runs, the source is the official VIES service, and it discloses the cost model (0.003 USDC via x402 or 2 Factline credits). Payment requirements and caching are exactly the kind of context 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 purpose and coverage, and dense with useful facts rather than filler. The opening sentence strings several clauses together, but each carries distinct information, so nothing reads as waste.

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 explains what comes back (valid/invalid plus registered name/address where the country shares them). With cost, caching, format rules, and return values all covered for a single-param tool, nothing an agent needs 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% with a single required parameter already documented. The description restates the input as 'VAT number with country prefix, e.g. IE6388047V,' mirroring the schema example, so it adds no meaning beyond structured fields – 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?

States a specific verb (validate) and resource (EU VAT number) with precise scope: all 27 member states plus Northern Ireland, via the official VIES service. It clearly distinguishes itself from siblings like kyc_check and email_verify through resource coverage.

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 explicit target use cases (invoicing, accounting, B2B onboarding, KYB, e-commerce), which frames when to reach for it. It stops short of naming an alternative sibling or stating when-not-to-use, but the context is clear.

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 readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds material behavioral context beyond that: the cost model (0.01 USDC via x402 or 5 credits of a Factline API key), that the checks run in parallel, that inputs are combinable ('Send any combination'), and the four possible verdict values.

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?

A single dense, front-loaded block that leads with the tool's identity, then capabilities, inputs, eligibility, and finally cost. Every sentence carries information an agent needs, with no padding or repetition.

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 provide the four verdict outcomes, plus cost, auth path, and input flexibility. It does not describe the shape of the per-check sub-results or explain the semantics of 'review' vs 'block_review', which is a minor remaining gap for a tool this complex.

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 only 29% (7 params, only vat and name have schema descriptions), so the description must compensate. It adds meaning for name, email, phone and vat ('send any combination'), but leaves type, country and birth_year completely undocumented, so it only partially fills the gap.

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 verb and resource ('One-call KYC/KYB onboarding check') and enumerates exactly what it screens (sanctions, email MX/disposable/role/typos, phone line type, EU VAT in VIES). Because it aggregates the individual capabilities exposed by siblings like email_verify, phone_verify, eu_vat_check and eu_sanctions_screen, an agent can readily tell it apart as the composite tool.

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 clear usage contexts ('signup, marketplace seller, payout and B2B onboarding agents'), which tells the agent when this tool is appropriate. It stops short of explicitly naming alternatives or when-not conditions (e.g., 'use email_verify alone if you only need email validation'), so it stays at a strong 4 rather than a full 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 cover read-only/open-world/idempotent. The description goes well beyond that by disclosing pricing (0.0015 USDC per address, 0.015 total, or 8 credits), the billing edge case that unfound addresses are flagged but not charged extra, and the optional energy-label output. This is exactly the extra behavioral context an agent needs before invoking 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-loads the core purpose and scope, then adds output fields, usage context, and pricing in a compact form. Three sentences with almost no waste; only the lengthy output-field enumeration borders on list-dumping, but it is informative rather than 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?

With no output schema, the description compensates by enumerating what is returned, and it discloses cost and the unfound-address billing rule. Combined with annotations covering the safety profile, an agent has everything needed to call this correctly and price 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% and both parameters are documented there, so the schema does the heavy lifting. The description mentions 'optionally the registered energy label' which maps to the include parameter but adds no syntax or format detail beyond the schema, 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 (bulk enrichment) and resource (up to 10 Netherlands addresses per call), and enumerates the returned data categories (BAG address, coordinates, CBS neighbourhood, crime, home value, energy label). The batch scope plus 'up to 10 per call' cleanly distinguishes it from the single-address sibling nl_address_lookup without needing to name it.

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?

Provides clear usage context ('For daily real estate, relocation, CRM and lead-enrichment pipelines'), which tells the agent where this tool fits. It does not, however, state when NOT to use it or explicitly point to nl_address_lookup for single addresses, so it stops short of full when/when-not 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?

Annotations cover safety (readOnly, idempotent, openWorld), and the description adds real value on top: the authoritative data source, exactly what is returned (existence, exact spelling, WGS84 coords, BAG ids, municipality, province, CBS code), and the cost/auth model (0.002 USDC via x402 or 1 Factline credit). Error/not-found behavior remains unstated.

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 operation and its inputs, then outputs, then use cases, then pricing. Every sentence carries distinct information (what, what-you-get, who-for, source, cost) with 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?

With no output schema and no annotations on cost, the description correctly compensates by enumerating return fields and pricing. Given five optional params and no required ones, what is missing is only the negative case (address not found) and its relation to the batch/reverse siblings.

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 already 100%, so the baseline is 3, and the description usefully explains the two input modes — structured postcode + house number versus free-text — which is the key decision an agent must make among these five optional parameters.

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 pair (verify/geocode) and a specific resource (Dutch address, postcode + huisnummer), and names the underlying register (BAG/Kadaster via PDOK). It does not, however, distinguish itself from close siblings like nl_address_batch or nl_address_reverse, which an agent would plausibly confuse it with.

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 lists target scenarios (KYC, onboarding, delivery, CRM cleanup, real estate agents), which implies when to reach for it, but gives no explicit when-not and no routing to the batch or reverse siblings. Usage context is present but alternatives are 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 declare readOnly, idempotent and open-world behavior, so the safety profile is covered. The description then adds materially more: the data provenance (Kadaster BAG via PDOK) and the paid cost model (0.002 USDC via x402 or 1 Factline credit), which an agent needs before invoking 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-loads the purpose, then layers audience, source and pricing in a logical order. The first sentence is a long run-on list of return fields, but every clause carries information an agent needs.

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 fields (distance, postcode, city, municipality, province, BAG ids, CBS buurt/wijk codes, nearby addresses). Combined with input format, source, and pricing, an agent has everything required 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 coverage is 100%, so the baseline is 3, but the description adds the coordinate system (WGS84), which the schema does not state. That is a genuine semantic addition beyond the example values in 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+resource (reverse geocoding of Dutch coordinates to official addresses) and names the exact standard (WGS84 in, BAG register out). It clearly distinguishes itself from sibling nl_address_lookup and nl_address_batch by name and by the reverse-geocoding direction.

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?

Provides clear usage context by naming target audiences (delivery, field service, mobility, real estate, mapping), which implies when the tool fits. It does not explicitly state when to prefer it over nl_address_lookup or nl_address_batch, so it stops short of full alternative routing.

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, openWorld), so the bar is low, and the description adds real value beyond them: the exact result contents (APK defect rate vs average, top-10 defects, recalls with component and risk, open-recall share, odometer rollback share, registrations) plus the RDW provenance and the ~450-model coverage limit. It does not state what happens for an unknown or non-covered model.

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.' followed by a single dense sentence enumerating the payload. Every clause earns its place given there is no output schema, though a trailing coverage note and the enumerated field list push it toward the long side.

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 does the work of describing return fields and data provenance, which is what an agent needs to decide and interpret. It omits error/empty behavior for models outside the ~450-model set, a minor gap for this complexity level.

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% for both parameters (make, model) and includes examples ('Volkswagen', 'Golf'), so the schema carries the meaning. The description adds only the geographic/data-domain framing, which is a baseline-3 level of added parameter context.

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 (reliability facts for a car model in the Netherlands) with the data source (RDW) and scope (~450 common passenger-car models). The 'car model' framing implicitly separates it from the per-vehicle siblings nl_vehicle_basic/nl_vehicle_report, but no sibling is named, so it stops short of a 5.

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: 'for a car model' suggests this is the right tool when you have make+model rather than a plate, and the 'Free' tag hints at a tier choice. There is no explicit when-to-use, when-not-to-use, or named alternative among the sibling tools.

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 behavior, and the description adds the pricing model (0.003 USDC via x402 or 2 credits of a Factline API key) plus data provenance (Politie open data, CBS). Those are meaningful behavioral facts an agent needs before invoking, though return shape/pagination is not discussed.

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 framing question ('Is this Netherlands neighbourhood safe?') so the agent sees the intent immediately, then layers coverage, consumers, source and price. It is dense but every sentence carries information; the only slight excess is the parenthetical Dutch term.

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 present, the description compensates by describing exactly what comes back: per-category counts, per-1,000-resident rates, the national rate and a ratio. Combined with source, cost and audience, an agent has everything needed to select and 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 coverage is 100%, so both parameters (postcode, CBS code) are already documented with examples in the schema. The description only reaffirms that either a postcode or a buurt code is accepted without adding syntax, format, or mutual-exclusivity guidance beyond the schema's 'Alternative' note. 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+resource: police-registered crime data for any Dutch postcode or CBS buurt code. The enumeration of crime categories (burglary, bicycle theft, vehicle crime, violence, vandalism) and the rate/ratio framing distinguishes it clearly from siblings like nl_neighbourhood or nl_flood_risk.

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 explicit intended consumers (relocation, real estate, insurance, travel agents), which tells the agent when this tool is contextually appropriate. It does not name an alternative sibling or state when-not-to-use (e.g. batch vs. single lookup), 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 readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context the annotations do not: the data source (RVO EP-Online national register), a cost model (0.005 USDC via x402 or 3 credits of a Factline key), and the 'none registered' negative-result path.

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?

Dense but well front-loaded: the core lookup and data source lead, followed by audience, input, and cost. Every clause carries information, though the source and cost sentences could be tightened slightly.

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 specifying return fields and the negative-result case, and it discloses the source and pricing model. An agent has everything needed to decide to call it and 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 five parameters are already documented in the schema, making 3 the baseline. The description's 'Input: postcode + house number' hints at the primary addressing path but actually understates the schema, which permits the free-text 'q' alternative with zero required params.

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 — 'Netherlands home energy label (EPC, energielabel) lookup by address' — and enumerates exactly what is returned (label A++++ to G, registration/expiry date, building type, energy index, or a 'none registered' outcome). That level of specificity clearly separates it from generic siblings like nl_home_basic or nl_home_report.

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?

Names intended audiences (real estate, mortgage, green-finance, ESG, renovation agents) which gives implied usage context, but never names an alternative tool or states when NOT to use this one versus nl_home_basic / nl_home_report. Useful framing, but exclusions and sibling routing are absent.

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 readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful context beyond that: the exact cost model (0.004 USDC via x402 or 2 API credits) and the authoritative data provenance, which an agent needs before invoking 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?

Purpose, data contents, audience and pricing are front-loaded in one dense but waste-free block; each clause carries information. It is slightly more packed than needed but nothing is redundant.

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 enumerates the returned risk metrics, so an agent understands the payload. The one gap is that 0 parameters are required while the description implies postcode + house number is the input, leaving the required-combination rule implicit.

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 documented in the schema, and the description only summarizes input as 'postcode + house number'. It omits mention of the free-text `q` alternative, `addition` and `house_letter`, adding little beyond what the schema already provides, so the 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 (Netherlands flood risk per address), the authority/source (Rijkswaterstaat LIWO), and the exact metrics returned (annual flood probability, scenarios, modelled depth, AHN ground height). This clearly distinguishes it from sibling data tools like 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?

The description names intended consumers (real estate, mortgage, insurance, ESG, relocation agents) and the input shape, which implies when it is relevant. But it gives no explicit when-to-use vs alternatives (e.g., whether nl_home_report already bundles flood risk) and no conditions under which it should be avoided.

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 readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds two useful behavioral facts beyond the schema: the call is free (implying no auth/cost friction) and the data provenance (BAG, CBS, Leefbaarometer), but says nothing about freshness, rate limits or latency.

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 short sentences, front-loaded with the cost signal and then the returned facts. Dense and largely waste-free, though the field list could be tightened into a more scannable form.

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 enumerates the returned fields, which is the right compensating move. However, it never explains the input contract — that either postcode + house_number or the free-text 'q' must be supplied despite zero required parameters — leaving a real ambiguity for the agent.

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 every parameter is self-documented, including the note that 'q' is an alternative to postcode. The description contributes no additional parameter guidance, so the 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?

The description names the resource ('a Dutch address') and enumerates exactly which facts are returned (year built, floor area, use, neighbourhood residents, average home value, Leefbaarometer percentile). An agent can tell it is a single-address lookup distinct from nl_home_compare or nl_home_report, though those siblings are never named.

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 'Free' hints at when to pick this over the paid siblings; there is no explicit statement such as 'use for a single address snapshot, use nl_home_compare for side-by-side'. No prerequisites or exclusions are given.

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, openWorld, idempotent), so the description's job is billing and scope — and it delivers: 0.08 USDC via x402 or 40 credits of a Factline API key, plus the input delimiter. It omits latency or rate-limit behavior, so a 5 is not earned.

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?

One dense but well front-loaded sentence: purpose first, then output inventory, then input format, then cost. It is long but nearly every clause carries a distinct fact (metrics list, best-per-metric, cost) that an agent needs before invoking.

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 wisely enumerates what comes back (liveability, crime, home values, distances, noise, air quality, ground height, best address per metric, full property report per address). Combined with pricing and input format, this is close to complete; only pagination/response-size and error behavior are absent.

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 single parameter already documents the ';' separator and the 2–5 range with an example. The description restates the same delimiter rule, adding no new syntax or format meaning beyond the schema, so the 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 (compare) plus resource (Dutch addresses) and an explicit scope of 2 to 5 inputs, in English. It is clearly distinguishable from nl_home_basic (single address basics) and nl_home_report (single full report) because it aggregates both plus the best-per-metric verdict.

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?

Names concrete use cases (house-hunting, relocation, real estate agents), which is clearer context than most siblings give. It does not, however, explicitly say when to prefer it over nl_home_report or nl_home_basic, nor when-not to use it (e.g. single-address cases).

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, open world), so the bar is lower. The description adds genuinely non-redundant behavioral context: this is a paid call costing 0.04 USDC via x402 or 20 credits of a Factline API key, which an agent must know before invoking. It does not mention rate limits, latency, or failure modes, so it stops short of 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 purpose and audience, then a dense but useful enumeration of report contents, closing with input format and pricing. The long content list is information-bearing rather than filler, though the single run-on enumeration could be trimmed slightly.

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 burden of describing what comes back, and it does so comprehensively via the data-domain list. It also discloses input format, target users, and payment mechanics, leaving nothing an agent needs to decide or call 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 100%, so the schema already documents all five parameters including the 'q' free-text alternative, addition, house_letter and house_number. The description only states 'Input: postcode + huisnummer', which actually understates the schema's flexibility; 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+resource: a Dutch property due-diligence report for one address, and enumerates the data domains it contains (year built, energy label, WOZ, crime, noise, air quality, amenities). This clearly differentiates it from narrower siblings like nl_home_basic and nl_home_compare.

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 names target audiences (real estate, relocation, mortgage agents) and local-language aliases (woningrapport, huis check), which implies usage. However it never states when to prefer this over nl_home_basic, nl_home_compare, nl_neighbourhood or the single-domain tools, and gives no exclusions or prerequisites.

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, so the safety profile is covered. The description adds genuinely useful context beyond structured fields: the data sources (CBS, Kadaster) and the payment requirement (0.003 USDC via x402 or 2 credits). The only untold trait is failure behavior for invalid or missing postcodes.

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 what the tool returns, then scope, then audience, then cost and sources. Dense and largely waste-free, though the audience sentence ('Property valuation context for...') is the least load-bearing part and could be trimmed.

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 names the return fields (WOZ value, trend, per-year municipal sale prices vs national), and it covers cost and sourcing. Only the response structure/pagination details and invalid-input behavior are left out, which is a minor gap for a read-only lookup.

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 both parameters are described there, so the schema already does the heavy lifting. The description reinforces that either a postcode or a CBS buurt code is accepted but adds no syntax, format, or default detail beyond the schema, so the 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?

Specific verb/resource: it states the exact data returned (WOZ neighbourhood value with trend, municipal vs national sale prices) and the accepted inputs (postcode or CBS buurt code). Clear enough that an agent knows what it fetches, but it never distinguishes itself from the overlapping nl_home_basic / nl_neighbourhood / nl_neighbourhood_summary siblings, so it falls short of a 5.

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 description names target audiences (real estate, mortgage, investment, relocation agents) but gives no explicit when-to-use or when-not conditions, no prerequisites, and no guidance on choosing it over a sibling like nl_neighbourhood_summary. Audience framing is not the same as usage 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuinely new behavior beyond that: the exact cost model (0.01 USDC via x402 or 5 credits) and the upstream data sources (CBS, Politie, Leefbaarometer). It omits what happens when neither postcode nor code is supplied, which matters since both parameters are optional.

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 deliverable, then use cases, then sources and cost in a single tight paragraph. No filler sentences; every clause carries information an agent can act on.

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 correctly compensates by enumerating the returned fields, and it discloses the paid access model. The only real gap is the unresolved requirement of at least one of postcode/code, which is left implicit despite both params being optional.

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 are already documented, and the schema itself labels 'code' as an alternative. The phrase 'for any postcode or CBS neighbourhood code' reinforces the either/or relationship but adds no format or validation detail beyond the schema examples (2517AS, BU05182245). 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?

Specific verb+resource with a full content inventory: population/age mix, housing, income, energy, amenity distances, crime, liveability. An agent immediately knows what comes back. However, it never differentiates itself from the close sibling nl_neighbourhood_summary, leaving the boundary between 'profile' and 'summary' unclear.

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 names concrete usage scenarios (real estate, relocation, retail site selection, market research) and states the access cost, which is useful routing context. But it never states when NOT to use it or points to the obvious alternative (nl_neighbourhood_summary, nl_crime, nl_house_prices) for narrower needs, so selection among 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 the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the bar is lower, and the description still adds genuine context: the tool is free, and the data provenance (CBS, Politie, Leefbaarometer) tells the agent the scope and trust level of the results. It omits any rate-limit, coverage, or freshness caveats, which keeps it out of 5 territory.

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 free/scope qualifier is front-loaded, followed by one dense sentence listing the payload and a short source line. Nothing is redundant, though the field enumeration is long enough to read as a spec dump rather than prose.

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 does the heavy lifting by enumerating the returned metrics, and annotations carry the safety profile. It stops short of describing response shape, units, or behavior for an unresolvable postcode, but for a read-only lookup it is essentially 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 description coverage is 100% and both parameters are documented in the schema with examples, so the baseline of 3 applies. The description only mentions 'for a postcode' and does not acknowledge the alternative CBS neighbourhood code input, so it adds no meaning 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 states a concrete resource (Dutch neighbourhood headline facts keyed by postcode) and enumerates the exact data returned — residents, WOZ value, sale price, owner-occupied share, liveability percentile, crime rate, distances. It never names the closely related sibling nl_neighbourhood or explains how this 'summary' differs from it, so an agent cannot fully disambiguate without opening both schemas.

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 'Free.' hints at a free-vs-paid tier distinction and 'for a postcode' implies the lookup context, but there is no explicit when-to-use, when-not-to-use, or named alternative. Given the sibling nl_neighbourhood exists and is presumably the paid/detailed counterpart, the absence of routing guidance is a real gap.

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, openWorld), so the description's job is to add context — and it does, disclosing the data provenance ('DUO open data') and the exact metric set returned, including benchmarks against national figures. It does not mention result limits, search radius, or whether a partial postcode widens the search.

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 cost signal and the core purpose, followed by the attribute list. The metric enumeration is long but each item is a distinct return field, so it earns its space; no filler or marketing language.

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 carry the return shape, and it does so thoroughly (distance, denomination, pupils, test-level shares, per-track pass rates). Gaps are minor: no indication of how many schools are returned, radius, or ordering.

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 the schema itself supplies format examples ('3511LX or 3511'). The description repeats 'Dutch postcode' without adding syntax or behavioral detail (e.g., how 4-digit vs 6-digit input changes results), so the 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 ('nearest primary and secondary schools to a Dutch postcode') and enumerates the returned attributes, making it immediately distinguishable from the home/vehicle/neighbourhood siblings. An agent can tell what this tool answers 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?

Usage is implied: supply a postcode, get nearby schools. The 'Free' prefix signals a no-cost option, which is mildly useful routing context, but there is no explicit when-to-use/when-not guidance or named alternative for school lookups.

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 readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds useful non-annotation context: the enumerated return fields, that the source is RDW, and that the call is free. It does not describe failure behavior for unknown plates or the response shape/format, so it adds only moderate value.

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 fragments with zero filler; the pricing note and source are front/back-loaded efficiently and the arrow form makes the input→output mapping scannable. It is arguably too terse to carry a verb, but nothing is wasted.

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 correctly compensates by enumerating the returned fields, and it names the data source (RDW). For a single-parameter read-only lookup this is close to complete; only error/edge-case behavior and sibling tiering are left unstated.

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 the single parameter already carries an example ('GT-722-F'), so the schema does the heavy lifting. The description restates the plate identity in Dutch context but adds no format, validation, or normalization detail beyond what the schema provides.

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 arrow notation states the resource (Dutch licence plate) and the exact payload it yields (make, model, age, fuel, Euro class, APK expiry, insurance, recall, odometer verdict, risk level), which is far more specific than the title alone. However it never names or contrasts with nl_vehicle_report, the obvious sibling, so the agent must infer the tier difference from the '(free)' label 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?

The word 'Free' hints that a paid tier exists, but the description never says when to use this tool versus nl_vehicle_report or any other sibling, nor does it state prerequisites (e.g. plate must be Dutch/registered). No exclusions or alternatives are given.

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, open-world. Description adds critical behavioral context: the report is paid (0.02 USDC via x402 or 10 API credits) and sourced from RDW open data. It does not mention rate limits or response pagination, but payment and source are valuable additions.

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 core purpose, then a dense list of report fields. The single long sentence packs information efficiently, though it lacks structural breaks. Every clause earns its place.

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, so the description compensates by enumerating returned fields (make, model, APK, defects, recalls, odometer verdict, etc.) and stating the language (English), source, and cost. Complete for invoking the tool 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 coverage is 100% for the single parameter, with an example plate. The description only says 'Input: Dutch licence plate', which adds no meaning 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?

States a specific verb+resource (Netherlands licence plate check) and enumerates the full report contents (make, model, APK, etc.), clearly distinguishing it as the detailed paid report. The agent can tell it is a Dutch vehicle history report, not a basic lookup or unrelated tool.

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?

Provides a target audience ('used-car buying, fleet, leasing and insurance agents') but does not name the alternative nl_vehicle_basic or state when not to use this paid report. Implied usage only, no explicit routing to siblings.

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 (readOnlyHint=true, idempotentHint=true, openWorldHint=true), so the bar is lower. The description adds real value by disclosing the cost model (0.003 USDC via x402 or 2 Factline credits) and the dual payment path — critical operational context an agent needs before calling. It does not mention rate limits or latency.

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?

Content is front-loaded (what it validates, then who it's for, then the national-number rule, then cost). It is dense but every clause carries information; the enumeration of line types and check types is long but purposeful.

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 validation facets (valid/possible, formatting, country/calling code, line type, SMS hint), so an agent knows what it gets back. Cost is disclosed. Only minor gaps remain (no error behavior, no rate limits).

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 documented, making 3 the baseline. The description goes beyond the schema by explaining the relationship between the two params — national numbers are accepted when paired with a country code, with a concrete example ('0612345678 with country=NL') — which is genuinely useful semantics not obvious from the schema alone.

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 ('Phone number validation for any country') and enumerates the exact checks performed (allocated number ranges, E.164, formatting, country/calling code, line type, SMS-capable hint). This cleanly distinguishes it from the closest sibling, email_verify.

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?

Names concrete use cases (signup, KYC, CRM cleanup, SMS and calling agents), giving clear context for when to reach for it. However, it never names an alternative or states when NOT to use it (e.g., vs email_verify or kyc_check), so it stops short of explicit routing guidance.

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