Dutch vehicle, address, building, elevation, holiday and demographics data, paid per call.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4/5 across 11 of 11 tools scored.
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.
catalogAInspectFree: 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.
global_fxAInspectFX conversion (ECB) — $0.003 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?
The description discloses pricing ($0.003 per call), the settlement context (x402, USDC on Base), and the informational-only nature, which goes beyond the schema. Since no annotations are provided, these behavioral traits help the agent understand the tool's constraints and side-effect-free usage.
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, information-dense sentence with a dash separator, front-loading the core purpose. Every element (source, pricing, caveat) earns its place without 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?
The tool is simple with three optional parameters and no output schema. The description adequately covers the purpose, source, and usage caveat, though it omits the return value format, which could be inferred from the conversion nature.
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 description does not elaborate on the parameters, but the schema already describes each parameter with its default values and ISO 4217 code types. With 100% schema coverage, the description is not required to add much, so a 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 identifies the tool as an FX conversion service using ECB reference rates. The verb 'conversion' and the resource 'FX/currency' make the purpose unambiguous, and it is distinct from the sibling tools which are unrelated (catalog, nl_address, etc.).
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 states the tool is for informational purposes and not for tradeable quotes, which helps the agent know when not to use it. It implies use when ECB rates are needed, though it does not name any alternative for other currency data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nl_addressAInspectDutch 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.
nl_buildingAInspectDutch building lookup (BAG) — $0.008 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?
With no annotations provided, the description carries the full burden. It discloses the per-call cost ($0.008) and data source (BAG via PDOK), which is useful. However, it does not mention read-only status, error behavior, authentication, or rate limits, leaving some ambiguity for a lookup 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 a single, front-loaded sentence that efficiently communicates the tool's purpose and key data fields. The inclusion of cost details is slightly extraneous for an AI agent but not overly verbose. Overall it is 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?
For a simple two-parameter lookup with no output schema, the description covers the essential context: what data is returned, the data source, and pricing. It does not explain return format or authentication, but these are less critical given the tool's simplicity, making it fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters (postcode and huisnummer) with clear descriptions and an example. The tool description adds no additional parameter-specific meaning beyond referencing the output fields, so the baseline score 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 identifies the tool as a Dutch building lookup with a specific verb ('lookup') and resource (BAG building data). It enumerates the fields returned (construction year, floor area, use function, status), which distinguishes it from sibling tools like nl_address or nl_demographics.
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 retrieving building attributes from a Dutch address, but it does not explicitly state when to use this tool over alternatives such as nl_address or nl_validate. There are no exclusions or alternative tool mentions, making the guidance only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nl_demographicsAInspectDutch 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.
nl_elevationAInspectDutch elevation (AHN / NAP height) — $0.006 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It adds useful context including cost per call, payment method, data source (AHN via PDOK), and the types of measurements returned. However, it does not explicitly state that this is a read-only operation or disclose any potential limitations like resolution or 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 very concise, consisting of two short sentences that pack in essential details: the tool's purpose, pricing, data source, and output metrics. Every word adds value, with no redundant or filler content.
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 has no output schema, the description appropriately mentions the three types of elevation measurements it returns. It also provides context about the geographic scope, data model, and source. It could be more complete by noting potential edge cases or error conditions, but for a simple query tool, it covers the essential information.
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 input schema already explains each parameter. The description adds minimal new parameter semantics beyond mentioning 'postcode or coordinate' as input options, which is already reflected in the schema. It does not provide additional format or usage details for the 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?
The description clearly identifies the tool as providing Dutch elevation data (AHN/NAP height), specifically ground height, surface height, and derived object height. It distinguishes itself from sibling tools like nl_building or nl_address by focusing on elevation metrics and the AHN height model.
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 states it works for a Dutch postcode or coordinate, giving clear context for when to use it. It doesn't explicitly mention when not to use it or name alternative tools, but the specific resource and input constraints strongly imply the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nl_school_holidaysAInspectDutch school holidays — $0.008 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, the description carries the burden. It discloses the cost per call ($0.008, USDC on Base) and hints at data freshness ('Current, merged'). However, it does not mention return format, error handling, or any side effects, which are relevant for a data lookup 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 a single, front-loaded sentence that packs in the resource, query dimensions, and cost without fluff. Every word serves a purpose, and the pricing information is essential for cost-aware tool selection.
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 three optional parameters, but the absence of an output schema puts the burden on the description to explain return values. It does not describe the response structure (e.g., holiday names, date ranges), and there are no examples. Still, the query dimensions and cost are covered, making it minimally adequate.
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 three parameters. The description echoes these parameters but adds no extra meaning or syntax details beyond echoing 'school year, region or date'.
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 school holidays, and states it is queryable by school year, region, or date. It distinguishes from siblings (e.g., nl_vacation_region) by its focus on school holidays, though it lacks an action verb like 'get' or 'list'.
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: the description mentions query dimensions (school year, region, date) but provides no explicit when-to-use guidance or alternatives. It does not state when not to use this tool or compare it to nl_vacation_region or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nl_vacation_regionAInspectVacation region resolver — $0.01 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?
With no annotations, the description carries a full burden. It adds useful context like cost ($0.01 per call) and payment method (x402, USDC on Base), but does not disclose behavior on invalid/incomplete input, parameter precedence, or return format. This leaves gaps for a spatial resolver without an output schema.
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 compact two-sentence structure: first sentence states the tool name and pricing, second sentence explains the function. Every phrase earns its place and is immediately readable, with 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?
Given no annotations and no output schema, the description should clarify more about expected output and edge cases. It mentions attaching 'current holiday dates' but doesn't describe the result structure or behavior when multiple parameters conflict. This is adequate for a simple lookup but incomplete for robust use.
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 covers 100% of parameters with clear descriptions (e.g., postcode resolves to gemeente/region). The tool description adds no additional meaning or relationship between parameters, so the baseline score 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 states a clear verb-and-resource action: 'Resolve a Dutch place to its vacation region' and 'attach that region's current holiday dates.' This distinguishes it from sibling tools like nl_address and nl_school_holidays by focusing on the Dutch vacation region classification (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 usage for resolving Dutch vacation regions and obtaining holiday dates, but does not explicitly state when to use this tool versus siblings (e.g., nl_school_holidays) or any exclusions. There are no alternative tool mentions, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nl_validateAInspectDutch 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.
nl_vehicleAInspectDutch vehicle lookup — $0.02 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 provided, the description carries the burden of behavioral disclosure. It usefully mentions the cost ($0.02 per call) and payment method (USDC on Base), which is valuable. However, it does not disclose potential failure modes, rate limits, or what happens when a plate is not found.
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, efficiently packed sentence. It front-loads the core purpose ('Dutch vehicle lookup') and then lists the key data categories and cost. Every element earns its place 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?
Given the low complexity (single optional-format parameter, no output schema), the description is reasonably complete. It covers purpose, data scope, and pricing. It could add return format or error behavior, but for a simple lookup tool, the missing context is not critical.
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 provides 100% coverage of the single parameter, including an example and note about case/format insensitivity. The description adds no extra parameter-level detail beyond the schema, so 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 uses a specific verb ('lookup') and identifies the exact resource ('Dutch vehicle') and data categories ('Registration, fuel/EV, APK... recalls'). It clearly distinguishes itself from sibling tools like nl_address and nl_validate by focusing on vehicle data by licence plate.
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 conveys when to use this tool: for Dutch licence plate information including registration, fuel/EV, APK, and recalls. It does not explicitly name alternatives or exclusions, but the scope is unambiguous enough that an agent can infer it's the right tool for vehicle lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sampleAInspectFree: 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_elevation, nl_validate, nl_demographics, global_fx. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is free, returns 'fixed sample data', and does not perform live lookups. This is transparent about the key behavioral traits, though it doesn't mention edge cases like invalid tool names or error responses.
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 concise sentences, front-loaded with key information ('Free: get...'). Every word adds value, and it avoids redundancy with the schema by not repeating the enum list.
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 tool with a single parameter, no output schema, and no annotations, the description is complete: it explains what it returns (sample data), why to use it (before paying), and its limitations (not live). This covers all essential context for an AI agent to select and invoke 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?
The schema provides 100% coverage for the single 'tool' parameter, including a descriptive enum. The description adds minimal semantics by referring to 'any paid tool', but this is already implied by the enum list. It doesn't enrich the parameter meaning beyond what the schema already offers.
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'. It uses a specific verb (get) and a specific resource (demo response), and distinguishes it from the sibling paid tools by emphasizing it returns samples, not live data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before paying' provides clear usage context, and 'not a live lookup' explicitly tells users when not to use it. It doesn't name specific alternatives, but it implies the paid tools themselves are for live data, which is sufficient for this simple sampling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!