Dutch address dossier, vehicle, building, elevation, holidays, demographics. Free samples first.
Free: list every data tool/endpoint with price, params and a free HTTP sample URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool is free and provides a flat list of all tools/endpoints with their metadata. The verb 'list' clearly implies a read-only operation, and the inclusion of 'every' indicates exhaustive enumeration. It doesn't mention auth requirements, rate limits, or response size, but for a simple catalog with zero parameters, these are minor gaps.
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 a single, front-loaded sentence that starts with the key 'Free:' modifier and immediately states the action ('list') and the resource. It contains no filler and every word contributes to the tool's purpose.
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 zero-parameter, read-only listing tool with no output schema, the description fully specifies the contents of the returned list: each tool/endpoint with its price, params, and a sample HTTP URL. This is sufficient for an agent to understand what the tool returns and when 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?
The tool has zero parameters and the schema is empty. The description's statement 'every data tool/endpoint' explicitly communicates that no filtering is needed or provided, which fully justifies the absence of parameters and adds meaning beyond the empty 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 uses the specific verb 'list' with a clear resource 'every data tool/endpoint' and enumerates the included attributes (price, params, HTTP sample URL). This clearly distinguishes the tool from sibling data-query tools, as it's a metadata/discovery tool rather than a data source.
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 implicitly indicates usage: it's a free, comprehensive listing of all available tools and their metadata, so an agent would use it to discover endpoints or pricing. However, it does not explicitly state when not to use it or name alternatives, though the siblings are obviously the specific data tools themselves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FX conversion (ECB) — $0.005 per call (x402, USDC on Base). Currency conversion using ECB euro reference rates. Informational only — not tradeable quotes.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ISO 4217 code, default USD. | |
| from | No | ISO 4217 code, default EUR. | |
| amount | No | Amount to convert, default 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the cost per call ($0.005), payment rail (x402, USDC on Base), data source (ECB euro reference rates), and the non-tradeable nature of the quotes. This goes beyond a basic function statement and provides useful operational context, though it doesn't mention rate limits or error behavior.
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 two sentences, front-loaded with the core purpose ('FX conversion (ECB)') and then succinctly adds cost, payment method, source, and caveat. No unnecessary words; every sentence 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?
For a simple conversion tool with three optional parameters and no output schema, the description covers the essential context: purpose, cost, payment rail, data source, and informational nature. The return format is implied but not explicitly stated, which is a minor gap. Overall, it's sufficiently complete for an agent to invoke 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?
The schema covers all three parameters (from, to, amount) with descriptions and defaults (EUR, USD, 1 respectively). The description adds the rate-source context but no additional parameter-specific meaning. Since schema coverage is 100%, the baseline of 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?
The description clearly states the tool performs FX conversion using ECB euro reference rates, with a specific verb and resource. It also distinguishes itself from tradeable quote services by stating 'Informational only — not tradeable quotes.' This makes the purpose unambiguous and distinct from sibling tools.
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 explicitly indicates the tool is for informational conversions and not for tradeable quotes, providing a clear context for when to use it (and when not to). It also mentions the cost and payment method, which helps an agent decide if it's appropriate. However, it doesn't name alternative tools, leaving a slight gap in direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dutch address lookup — $0.005 per call (x402, USDC on Base). Resolve a Dutch postcode + house number to a full address (street, city, gemeente, province, WGS84 + RD coordinates), or reverse-geocode coordinates to the nearest address.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude for reverse geocoding. | |
| lon | No | Longitude for reverse geocoding. | |
| postcode | No | Dutch postcode for forward lookup (e.g. 1011AC). | |
| huisnummer | No | House number for forward lookup. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the cost ($0.005 per call, x402, USDC on Base) and the output fields (street, city, gemeente, province, WGS84 + RD coordinates). However, it does not mention authentication requirements, rate limits, error handling for invalid inputs, or confirm read-only behavior explicitly.
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 two sentences long, front-loaded with the tool name and pricing, and every clause adds essential information. It covers cost, purpose, modes, and output fields without redundancy or 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 lists the key return values, making the tool's result clear. It adequately covers both use cases and parameter combinations. However, it omits details like error conditions or how to handle cases where both forward and reverse inputs are provided, leaving minor ambiguity.
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 descriptions for all four parameters. The description adds value by grouping postcode+huisnummer as the forward lookup pair and lat/lon as the reverse geocoding pair, clarifying how the parameters relate. It also specifies the postcode format example ('1011AC') in the schema, but the description's mode grouping goes beyond individual parameter docs.
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 clearly states 'Dutch address lookup' and specifies the two modes: forward lookup from postcode+house number and reverse geocoding from coordinates. It distinguishes itself from sibling tools like nl_building and nl_validate by focusing on address resolution and listing specific output fields.
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 explains when to use forward vs reverse geocoding ('Resolve a Dutch postcode + house number... or reverse-geocode coordinates'), but does not mention any alternatives or exclusions relative to sibling tools. The usage context is implied rather than explicitly contrasted with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dutch building lookup (BAG) — $0.010 per call (x402, USDC on Base). Construction year (bouwjaar), floor area (oppervlakte), use function (gebruiksdoel) and status for a Dutch address, from the BAG via PDOK.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | Dutch postcode, e.g. 1011AC. | |
| huisnummer | Yes | House number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses per-call cost and data source, and the word 'lookup' implies a read-only operation. However, it does not mention error behavior, response format, or any limits/edge cases, leaving gaps.
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 a single, well-structured sentence that packs in the country, source, cost, and key output fields. Every element earns its place; there is no fluff 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?
For a simple two-parameter lookup with no output schema, the description covers purpose, cost, source, and returns a list of key fields. It lacks explicit usage alternatives and response structure, but the omitted details are unlikely to cause misselection or misuse.
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?
The input schema already describes both parameters (postcode and huisnummer) with examples and constraints, achieving 100% schema description coverage. The accompanying description adds no additional parameter-level semantics beyond what the schema provides, so it meets the 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 clearly identifies a Dutch building lookup (BAG) and lists specific data fields (construction year, floor area, use function, status). It distinguishes from sibling tools like nl_address by focusing on building attributes rather than address formatting or validation.
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 context is implied by mentioning 'for a Dutch address' and the BAG/PDOK source, but there is no explicit guidance on when to choose this over nl_address or nl_validate. No exclusions or alternative comparisons are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dutch municipality demographics — $0.005 per call (x402, USDC on Base). CBS key figures for a Dutch municipality (population, men/women, households, average household size, population density), by gemeente name or CBS code.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | CBS municipality code (e.g. GM0363). | |
| gemeente | No | Municipality name (CBS spelling, e.g. 's-Gravenhage). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the $0.005 per-call cost and USDC on Base payment method, along with the specific metrics returned. It does not mention rate limits or error handling, but for a read-only data query this is reasonable coverage.
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 a single sentence that front-loads the tool's purpose, includes essential cost information, and lists key output fields without any waste. Every part earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description enumerates the output metrics, which serves as implicit output documentation since no output schema exists, and clarifies the two lookup methods. It lacks details on required parameters (neither is required) and potential error states, but is otherwise complete for a simple data-retrieval 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?
Both parameters are fully described in the input schema (CBS code and municipality name), providing 100% coverage. The description reinforces how they are used ('by gemeente name or CBS code') and lists key figures, but adds no additional syntax or format details beyond what the schema already 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 description clearly identifies the resource (Dutch municipality demographics) and specific data points (population, households, density), distinguishing it from sibling tools that cover other Dutch data types. However, it lacks an explicit verb like 'get' or 'retrieve', relying on a noun phrase to convey the action.
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 implies usage when demographic data for a Dutch municipality is needed, by name or CBS code. It does not explicitly state when to prefer this tool over siblings or provide usage scenarios or exclusions, but the content makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dutch address dossier — $0.025 per call (x402, USDC on Base). One call, four registers for a Dutch address: the address itself, its BAG building (bouwjaar, floor area, use function), its AHN height above NAP, and CBS key figures for its gemeente.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | Dutch postcode, e.g. 1011AC. | |
| huisnummer | Yes | House number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the cost ($0.025 per call via x402/USDC on Base) and the exact data registers returned, which is valuable for an agent deciding whether to invoke the tool. It does not mention rate limits, error handling, or a read-only status, but the lack of any side effects and the simple query nature mitigate this.
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 a single, tightly worded sentence that front-loads the tool name and cost, then lists the key content. Every clause is informative, with no filler or repetition. It is concise yet structured enough to convey the value proposition clearly.
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?
Given the tool's moderate complexity (2 parameters, 100% schema coverage, no output schema), the description sufficiently sets expectations for the return data by enumerating the four registers and giving examples (bouwjaar, floor area, use function, NAP height, CBS key figures). It also includes cost and settlement context. It does not describe exact output formatting, but that is not essential for a dossier tool when no output schema exists.
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?
The input schema covers 100% of parameters with descriptions for both 'postcode' and 'huisnummer.' The tool description does not add parameter-specific details beyond what the schema provides, instead focusing on the output registers. This meets the baseline for schema coverage, but the description adds no extra parameter semantics.
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 clearly identifies the tool as a 'Dutch address dossier' and specifies that one call returns four registers: address, BAG building, AHN height, and CBS key figures. This distinguishes it from siblings like nl_address, nl_building, nl_elevation, and nl_demographics by emphasizing the combined, multi-register response.
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 implies usage when a comprehensive Dutch address dossier is needed, especially highlighting efficiency with 'One call, four registers.' However, it does not explicitly state when to use this tool versus calling individual sibling tools (e.g., nl_address, nl_building) separately, nor does it provide exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dutch elevation (AHN / NAP height) — $0.010 per call (x402, USDC on Base). Ground height above NAP, surface height and derived object height for a Dutch postcode or coordinate, from the AHN 0.5 m height model via PDOK.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | WGS84 latitude; use with lon instead of postcode. | |
| lon | No | WGS84 longitude; use with lat instead of postcode. | |
| postcode | No | Dutch postcode, e.g. 3511LM (resolved to its centroid). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful context: the $0.010 per call cost, the data source (AHN via PDOK), and the types of heights returned. Since this is a read-only lookup, lack of side-effect warnings is appropriate, though it doesn't mention output format or error handling.
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 a single, front-loaded sentence that conveys the core purpose, data source, and cost without waste. Every part adds value, and it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only three optional parameters and no output schema. The description covers the essential inputs, outputs, source, and cost, which is sufficient for a read-only API. It could mention that lat/lon are WGS84 (though schema does), but overall it is complete enough.
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 each parameter (lat, lon, postcode) with constraints and usage. The description adds little beyond summarizing that postcode or coordinate can be used, which is already implied by the schema descriptions. 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?
The description clearly states the tool provides Dutch elevation data (AHN/NAP height) and specifies the exact outputs: ground height, surface height, and derived object height. It also names the data source and model (AHN 0.5m via PDOK), making it distinct from sibling tools like nl_address or nl_building.
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 implies usage for Dutch locations via postcode or coordinate, and is naturally scoped to the Netherlands. However, it does not explicitly mention alternatives or when not to use this tool, relying on the name and purpose to differentiate from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dutch school holidays — $0.005 per call (x402, USDC on Base). Current, merged Dutch school-holiday dates, queryable by school year, region or a specific date.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD — returns the holiday (if any) covering that date. | |
| year | No | School year, e.g. 2025-2026. Defaults to the current one. | |
| region | No | noord | midden | zuid. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the cost per call ($0.005) and the nature of the data ('Current, merged'), which is useful. However, it does not explicitly state that it is a read-only operation, nor does it describe output format, rate limits, or error behavior.
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 a single sentence that efficiently conveys the resource, cost, and query dimensions. It is front-loaded with the tool's purpose. The inclusion of exact pricing is somewhat tangential but relevant for cost-aware agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 optional parameters and no output schema, so the description should ideally hint at return values or behavior. It gives the query options and pricing but does not describe the response format or what 'merged' dates look like. For a simple query tool, this is adequate but incomplete.
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 each parameter. The description adds the context that data is 'current' and mentions the same filters (year, region, date), but adds no new syntax or format details beyond the schema. This meets the 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 clearly states that the tool provides Dutch school-holiday dates and lists the query dimensions (school year, region, specific date). It uses the verb 'queryable' to indicate retrieval, making the purpose evident. However, it does not explicitly distinguish itself from the sibling tool nl_vacation_region, which may be related.
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 implies usage by mentioning queryable fields and 'current' data, but it provides no explicit guidance on when to use this tool versus alternatives like nl_vacation_region. There are no stated exclusions or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vacation region resolver — $0.010 per call (x402, USDC on Base). Resolve a Dutch place to its vacation region (noord/midden/zuid) and attach that region's current holiday dates.
| Name | Required | Description | Default |
|---|---|---|---|
| plaats | No | Place/city name. | |
| gemeente | No | Municipality name. | |
| postcode | No | Dutch postcode, e.g. 1011AC (resolved to gemeente/region). | |
| province | No | Province name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It discloses the per-call cost, the allowed region values, and the attach action, but does not specify input-resolution behavior (e.g., precedence among plaats, gemeente, postcode, province) or failure/response details.
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 sentence that front-loads the tool's purpose and pricing, then states the action and output. Every phrase adds value 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?
For a resolver with four optional identifier fields and no output schema, the description states high-level behavior but leaves ambiguity about which parameter(s) to provide and what the return payload looks like. It is serviceable but not fully complete for an agent to invoke reliably.
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?
Input schema covers all four parameters with descriptions (100% coverage), so baseline is 3. The description adds no additional parameter meaning beyond saying 'Dutch place' and does not clarify how the optional identifiers are prioritized or combined.
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?
Description uses specific verb 'resolve' with clear resource (Dutch place) and outputs (vacation region and current holiday dates). It distinguishes itself from sibling nl_school_holidays by focusing on vacation regions (noord/midden/zuid).
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 implies when to use (when a Dutch vacation region and associated holiday dates are needed) but provides no explicit when-not-to-use guidance or alternatives such as nl_school_holidays. Usage context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dutch identifier validation — $0.001 per call (x402, USDC on Base). Offline validation of a Dutch identifier: BSN (elfproef), IBAN (structure + mod-97 + bank), or kenteken (sidecode format).
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Identifier type: bsn, iban or kenteken. | |
| value | Yes | The value to validate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that validation is offline (performing local checks without external calls), specifies the validation algorithms for each type, and transparently discloses the cost and payment method. This exceeds basic expectations, though it does not state the return format or behavior on invalid input.
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 a single, well-structured sentence that packs in the tool's scope, examples, validation specifics, and pricing without any fluff. Parentheticals efficiently list the identifier types and their validation methods, making it easy to scan.
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?
Given the tool's low complexity (two simple parameters) and lack of output schema, the description provides sufficient context: what it does, for which identifiers, and how much it costs. It could mention what the validation result looks like, but the essential information for selecting and invoking 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%, so parameters are already described. The description adds valuable meaning by explaining what each type enum actually validates (e.g., elfproef for BSN, mod-97 for IBAN), going beyond the schema to clarify the purpose and behavior of each parameter value.
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 uses a specific verb 'validation' with a clear resource 'Dutch identifier' and explicitly enumerates the three supported types (BSN, IBAN, kenteken). This distinguishes it from sibling tools like nl_address or nl_vehicle, making its purpose 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?
The description clearly implies when to use the tool: for validating Dutch identifiers of the listed types. It does not explicitly exclude other types or name alternatives, but the context of sibling tools and the clear scope make the appropriate usage evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dutch vehicle lookup — $0.020 per call (x402, USDC on Base). Registration, fuel/EV, APK (roadworthiness) and open recalls (terugroepacties) for a Dutch licence plate (kenteken).
| Name | Required | Description | Default |
|---|---|---|---|
| kenteken | Yes | Dutch licence plate, case/format-insensitive (e.g. 0001TJ). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses the per-call fee and enumerates the data categories returned, which gives a clear behavioral picture. It does not discuss rate limits or optional filters, but the scope is well-defined for a simple 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?
The description is a single, front-loaded sentence that immediately states the tool's purpose and then lists its features and pricing. No 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?
Given the single-parameter schema and absence of an output schema, the description provides sufficient context by naming the four result categories and the cost. It doesn't specify the return format, but for this simple lookup that may not be necessary.
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?
The schema already documents the parameter fully (Dutch licence plate, case-insensitive, with an example), so the description adds little beyond confirming 'kenteken' is the plate. Baseline 3 is appropriate given high schema coverage.
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?
Clearly identifies itself as a Dutch vehicle lookup tool, enumerating specific data categories (registration, fuel/EV, APK, recalls) that distinguish it from sibling tools focused on other Dutch data domains.
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 context of sibling tools makes it clear this is the only vehicle-related tool, so the use case is unambiguous. However, it does not explicitly state when not to use it or mention any alternative; it relies on the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free: get the documented demo response for any paid tool, so you can see the exact response shape before paying. Returns fixed sample data, not a live lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Which tool to sample: nl_vehicle, nl_school_holidays, nl_vacation_region, nl_address, nl_building, nl_dossier, nl_elevation, nl_validate, nl_demographics, global_fx. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it is free, returns fixed sample data (not live queries), and provides the 'documented demo response,' setting correct expectations about the non-live nature. It does not elaborate on error handling or rate limits, but the core behavior is transparent for this simple 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 two sentences, front-loaded with the key benefit (Free) and purpose. Every word adds value, with no fluff or repetition of schema details.
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?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description is fully sufficient. It tells the agent what the tool does, when to use it, and what to expect in return (fixed sample data), making it complete for effective selection and invocation.
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?
The input schema fully describes the single `tool` parameter with an enum and a description listing all valid values, so schema coverage is 100%. The description adds no additional parameter semantics beyond what the schema already provides, meeting the baseline for high schema coverage.
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 clearly states the tool's purpose: 'get the documented demo response for any paid tool' to see the exact response shape before paying. It distinguishes itself from sibling tools by emphasizing it returns fixed sample data, not a live lookup, positioning it as a preview/sample 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?
The description provides clear context for when to use this tool: 'before paying' to preview the response shape. It does not explicitly name alternatives but implies using this instead of calling paid tools directly for exploration. No exclusions are stated, but the use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Dutch property report by address: build year, energy label, neighbourhood, monument, schools.
French address intelligence: 18.6M sold prices, energy, risk, crime and schools — each sourced.
DwellData: typed US real-estate feeds — deals, distress, auctions, leads, address lookup.
Light: Download via ZIP code, official-source lookup. Platform-hosted, pay per query with prepaid cr
Add one secure layer between your agents and this server.
Each tool targets a distinct data source or function: address lookup, building info, demographics, elevation, school holidays, vehicle lookup, validation, currency conversion, plus meta-tools for catalog and sample responses. There is no meaningful overlap between any pair of tools.
The Dutch-specific tools all follow a consistent 'nl_<subject>' pattern (nl_address, nl_building, etc.), and all names use snake_case. However, three tools (catalog, global_fx, sample) break the prefix pattern, creating a minor inconsistency but remaining clear and readable.
With 11 tools, the server is well-scoped for a Dutch open data API. Each tool covers a distinct data domain, and the count is within the ideal range without feeling excessive or sparse.
The tool surface covers a broad range of Dutch open data lookups, including addresses, buildings, demographics, elevation, holidays, and vehicles, along with validation and a sample mechanism. Minor gaps exist (e.g., no weather or property value data), but the core domain is well represented.
