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

Annotations provide readOnlyHint and openWorldHint; description adds authentication requirement (BAG_API_KEY) and fallback behavior (Locatieserver-only when missing), plus lists the specific data fields returned. No contradiction.

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, no wasted words. First sentence states purpose with key details; second provides usage guidance. Front-loaded and efficient.

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 2 parameters, 100% schema coverage, no output schema (but return fields listed), and annotations present, the description fully covers purpose, usage, fallback, and alternative. No gaps.

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 already describes both parameters with 100% coverage. Description adds value by clarifying that either query or pdok_id must be provided and that pdok_id is preferred when known.

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 resolves an address and fetches authoritative BAG details, listing specific fields. It also distinguishes from sibling bag_linked_data_select by specifying when to use this tool instead.

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 states when to use this tool (when linked-data SPARQL endpoint is down or when address id is known) and mentions fallback behavior. Does not explicitly state when not to use, but provides clear context.

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 indicate readOnlyHint and openWorldHint. The description adds that the tool is read-only and enforces SELECT-only queries with a LIMIT cap, which aligns with and extends the annotations. No contradictions; the added detail on query restrictions is valuable.

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 conveys all key information without extraneous words. It is front-loaded with the main action and constraints, making it highly efficient.

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 two parameters and no output schema, the description covers the essential purpose and constraints. However, it omits details on return format, error handling, and query construction conventions (e.g., required prefixes). For a SPARQL query tool, this information is important for proper usage, leaving the description somewhat 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 coverage is 0% as no parameter descriptions are provided in the schema. The description adds meaning by stating the 'query' parameter is a SPARQL SELECT query and the 'limit' parameter is capped. However, it does not explain the required query format (e.g., prefixes, endpoint specifics), so it provides moderate value beyond the raw 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 clearly states it executes a read-only SPARQL SELECT query on Kadaster BAG linked data (buildings and addresses), and specifies that only SELECT queries are allowed with a capped LIMIT. This uniquely identifies the tool's function and distinguishes it from sibling tools like bag_address_detail or rce_linked_data_select.

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 that only SELECT queries are allowed and LIMIT is capped, providing clear constraints. However, it does not explicitly compare to sibling tools or advise when to use this over alternatives like bag_lookup_address. The context is clear but lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, which cover safety and data volatility. The description adds that it uses PDOK Locatieserver, providing source transparency, but does not elaborate on other behavioral traits like pagination, result limits, or rate limits. Minor added value over annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two sentences with no wasted words. First sentence states purpose and data source; second lists search types. Front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Moderate completeness: given 4 parameters, no output schema, and annotations that cover readOnly/openWorld, the description provides core purpose but lacks details on default rows (10), minimum/maximum, required parameters (none), and return format. Without output schema, some indication of result structure would help. Annotations partially compensate.

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 has 4 parameters with 0% description coverage. The description mentions 'free text, postcode, or house number', which maps to query, postcode, and huisnummer parameters, adding meaning beyond bare schema. However, it omits the rows parameter (page size) and does not explain parameter constraints, so compensation is partial.

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 clearly states the tool looks up BAG address details via PDOK Locatieserver, and lists specific search methods (free text, postcode, house number). This distinguishes it from sibling tools like bag_address_detail (specific ID lookup) and bag_linked_data_select (linked 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?

No guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or comparison with bag_address_detail or other search tools. The description only states what it does, not when it's appropriate.

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?

The description adds value beyond annotations by noting that geometry can be large ('large for gemeente/provincie polygons'), which helps set expectations. It also specifies the return fields and optional geometry. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences: the first states the purpose and source, the second lists filters and returns. It is front-loaded and free of superfluous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 11 parameters and no output schema, the description covers the essential purpose but lacks details on pagination, output formats, error handling, and many parameters. It is adequate for a search tool but could be more comprehensive.

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 explains the key parameters (naam, code, bbox, includeGeometry) and the administrative level (niveau). However, with 45% schema description coverage, many parameters (top, limit, offset, dryRun, verbose, outputFormat) are not described, leaving gaps. The description partially compensates but not fully.

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 specifically states 'Search Dutch administrative areas (gemeente/provincie/land) via PDOK Bestuurlijke Gebieden OGC API Features', clearly indicating the tool's purpose, resource, and scope. It distinguishes itself from sibling tools focused on addresses, buildings, or other 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 description provides clear context for when to use the tool (searching Dutch administrative areas) and mentions filter options (naam, code, bbox). It does not explicitly list alternatives or when not to use it, but the specificity of the domain implicitly guides usage.

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 indicate readOnlyHint=true and openWorldHint=true. The description adds minor behavioral context (bbox-driven, performance advice) but does not cover rate limits, authentication, or other traits. Since annotations carry the burden, a score of 3 is appropriate.

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 concise (two sentences) and front-loaded with purpose. However, it could be more structured, e.g., separating input constraints or listing output details more clearly. Still, it is efficient and informative.

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 9 parameters and no output schema, the description covers the main purpose and key parameters (bbox, collectie, geometry) but lacks details on pagination, output formats beyond JSON/GeoJSON, and error handling. It is adequate but could be more comprehensive.

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 low (33%). The description adds meaning for 'collectie' (lists collections) and 'bbox' (EPSG:28992, keep small) but fails to describe other parameters like 'top', 'limit', 'offset', 'outputFormat', etc. Given low coverage, description should compensate but does so only partially.

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 searches Dutch cadastral parcels and map objects via PDOK OGC API, specifying it is bbox-driven, lists collections, and describes return fields. This is specific and distinguishes it 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 provides context for usage ('bbox-driven', 'keep it small') but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusion criteria or alternative tools are mentioned.

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 indicate readOnlyHint=true and openWorldHint=true. The description adds detail about the specific data returned (severity, crash type, vehicle types, coordinates), which is valuable beyond annotations. No contradictions.

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 function, and includes keywords for searchability. Every sentence contributes.

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 11 parameters and no output schema, the description covers the broad purpose and return types but omits details on pagination, debug parameters (dryRun, verbose), and result format nuances. It is adequate but not comprehensive.

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 45%, and the description does not add meaningful detail for most parameters beyond what is in the schema. It mentions bbox and the return structure but does not clarify parameters like top, limit, offset, dryRun, verbose, or outputFormat. The description should compensate for low coverage but does not.

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 it searches Dutch road traffic accidents via WFS GetFeature within a bbox, specifying return fields (severity, crash type, vehicle types, location, coordinates). It stands out from sibling tools like bag_address_detail or data_politie_search by being uniquely about accidents.

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 emphasizes the required bbox and that searching the full dataset is not allowed, giving a clear usage constraint. It does not explicitly state when not to use or offer alternatives, but the bbox requirement is a strong guideline.

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?

The description adds useful behavioral context beyond the annotations: it mentions the tool accesses public REST services, returns location in two coordinate systems (WGS84 and RD), quality regime, and registration metadata. This gives the agent a clearer picture of the output. Annotations already declare it read-only and open-world.

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 paragraph of three sentences, front-loaded with the tool's purpose and core usage patterns. No redundant or filler content. Every sentence provides essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers the return format for the direct object lookup (location, quality regime, metadata) but is vague about the search mode output (reference-code domains). With seven parameters, only the query parameter is explained in context, leaving gaps for the others.

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?

With only 14% schema coverage, the description explains the query parameter's two valid forms (object ID or keyword) but does not mention the other six parameters (top, limit, offset, dryRun, verbose, outputFormat). Their defaults and constraints are in the schema, but the description adds little beyond the query parameter.

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 queries the Dutch BRO subsurface register and specifies two distinct use cases: fetching a single object by ID and searching reference-code domains by keyword. Examples of IDs and keywords are provided, distinguishing it from the many sibling tools that cover other Dutch government data sources.

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 what the tool does but does not explicitly state when to use this tool over alternatives or when not to use it. There is no comparison with sibling tools or guidance on which mode to choose based on user need.

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=true and openWorldHint=true, so the tool is clearly safe and open-ended. The description adds the OData source and dimension exploration mode, but does not explain pagination, rate limits, or the effect of the 'dryRun' parameter. Behavioral transparency is adequate but not enhanced significantly.

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 three sentences, each adding value: purpose+source, filterable fields, dimension exploration. No wasted words, front-loaded.

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 13 parameters, none required, with options for pagination, dry run, and output format. The description only covers the search filter aspect and dimension exploration, missing explanations for pagination, dryRun, verbose, and outputFormat behavior. Given the complexity, the description is 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 54%, leaving several parameters (top, limit, offset, dryRun, verbose) undocumented in the schema. The tool description mentions filtering fields but does not explain these numeric/boolean parameters. However, it does add context about OData source and dimension exploration. Parameter semantics are partially improved but not fully compensated.

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 explicitly states the tool searches CBS Iv3 municipal/provincial finance statistics, listing four filter dimensions and an explore mode for dimension values. This distinguishes it from sibling CBS tools like cbs_observations (general observations) and cbs_tables_search (table metadata).

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 CBS finance statistics with filtering, but does not specify when to use alternatives like cbs_observations or cbs_tables_search. It lacks explicit when-not or alternative 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=true and openWorldHint=true, so read-only behavior is covered. Description adds no additional behavioral context (e.g., pagination, rate limits, data volume warnings). Minimal added value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: one sentence and a phrase. No redundant words. However, brevity compromises informativeness; a bit more structure would be beneficial.

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?

Complex tool with 9 parameters, no output schema, and nested objects. Description omits crucial context: how to obtain tableId, pagination behavior, output format defaults, and limitations. Lacks completeness for effective agent 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?

Schema coverage is 0%, so description must compensate. Only mentions 'column selection' and 'dimension filtering' (implying select and filters parameters). Fails to explain other 7 parameters (top, limit, offset, dryRun, verbose, outputFormat, tableId). Insufficient for 9-parameter tool.

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 states verb 'Fetch' and resource 'observations (data rows) from a CBS statistical table'. Distinct from siblings like cbs_table_info (metadata) and cbs_tables_search (table discovery). Specific verb+resource with implied scope.

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?

Implies use when needing data rows from CBS tables, but no explicit guidance on when to use alternatives or when not to use. Context is clear but lacks exclusion criteria.

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 indicate readOnlyHint=true and openWorldHint=true, covering safety and variability. The description adds no additional behavioral details (e.g., error handling, authentication needs, response size). With annotations, a score of 3 is appropriate as the description does not contradict or significantly enhance transparency.

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 with no unnecessary words. Every part earns its place, providing essential information efficiently.

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 one parameter and no output schema. The description covers the basic purpose but lacks detail on what exactly 'metadata and column definitions' includes (e.g., output format, typical fields). It is minimally complete but could be more informative.

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 0%, so the description must compensate. The description mentions 'by table ID' but does not explain what constitutes a valid table ID (format, examples). This adds minimal meaning beyond the schema's type 'string'.

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 retrieves metadata and column definitions for a specific CBS statistical table by table ID. The verb 'Get' and resource description are specific and distinct from sibling tools like cbs_tables_search (which lists tables) and cbs_observations (which retrieves observations).

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 table ID is known, but does not explicitly state when to use this tool versus alternatives (e.g., when to use cbs_tables_search first to find the ID). No exclusions or prerequisites are provided.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=true. Description adds no behavioral context (e.g., pagination, rate limits, output nature). Minimal added 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?

Two concise sentences, front-loaded with purpose, no wasted words. Could include more detail without harming conciseness.

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 7 parameters, no output schema, and many sibling tools, the description is too minimal. Missing information on pagination, output format options, dryRun/verbose semantics, and when to choose this over related CBS tools.

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 14% (only 'query' described). The description only mentions topic keywords; it does not explain top, limit, offset, dryRun, verbose, or outputFormat. Fails to compensate for low 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?

States clear verb+resource ('Search CBS statistical tables') and provides usage hint (use keywords). However, does not distinguish from sibling tools like cbs_iv3_search, cbs_observations, or cbs_table_info.

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?

Advises using concise Dutch/English keywords and not full questions, but lacks explicit guidance on when to use this tool vs alternatives or when not to use it.

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 indicate readOnlyHint and openWorldHint. The description adds useful behavioral context: it uses KOOP SRU, matches against the 'keyword' index, and returns specific fields and a link. This goes beyond annotations without contradiction.

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 concise, consisting of four sentences with no wasted words. It front-loads the main purpose and includes essential details about return fields and input constraints.

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 7 parameters and no output schema, the description is insufficient. It omits explanations for pagination parameters (top, limit, offset), output formats, and debugging options. Users lack enough context to use the tool effectively beyond a basic query.

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 14%. The description adds value for the 'query' parameter by reinforcing that only topic keywords should be passed. However, it does not explain other parameters (top, limit, offset, dryRun, verbose, outputFormat), leaving them undocumented in both schema and description.

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 searches Dutch decentralised/local regulations (CVDR) via KOOP SRU, listing specific return fields. It specifies the scope (municipal, provincial, water-authority bylaws) and the required input type (topic keywords), distinguishing it from sibling tools that cover other Dutch government 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 description instructs to 'Pass topic keywords only,' providing clear usage context. It implies when to use this tool (for CVDR regulations) versus other sibling tools for different Dutch legal documents, but does not explicitly state when not to use it or name alternatives.

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 and openWorldHint, so the description's simple 'Search' is consistent. However, the description adds no behavioral detail (e.g., pagination, rate limits, result structure) beyond what annotations convey, so it does not enhance transparency.

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 is concise and directly states the purpose. It earns its place without unnecessary words, though it could be slightly more informative about parameters.

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 2 parameters and no output schema, the description provides adequate context about the domain (EU open data) but lacks details on result format, pagination, or how to use the 'rows' parameter. It is minimally viable but has clear gaps for a search tool with 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 description coverage is 50% (only 'query' has a description). The tool description mentions 'topic keywords' which aligns with 'query', but it does not explain the 'rows' parameter or its default limit. The description adds no extra meaning beyond what the schema provides, failing to compensate for the undocumented 'rows' parameter.

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 verb (Search), the specific resource (EU open data portal at data.europa.eu), and the method (by topic keywords). It effectively distinguishes from sibling tools like data_overheid_datasets_search by naming the EU portal explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives like data_overheid_datasets_search or eurostat_datasets_search. Lacks explicit context for appropriate use cases or exclusions.

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

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

Annotations already provide readOnlyHint and openWorldHint. The description adds no further behavioral context such as rate limits, response format, or dependencies. With annotations covering safety, this is adequate but not enhanced.

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 concise sentence with no unnecessary words. It efficiently communicates the core action and resource.

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 one parameter and no output schema. The description is minimal but adequate for a simple retrieval. However, 'full details' is vague, and the lack of output schema leaves the agent uninformed about the structure of 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 coverage is 0% for the only parameter 'id'. The description says 'by ID' but does not specify format, source, or example. For a simple string parameter, minimal guidance is acceptable, but zero coverage leaves the agent without clarity on what constitutes a valid ID.

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 action ('Get full details'), the resource ('a specific dataset'), and the source ('data.overheid.nl'), with a specific method ('by ID'). This distinguishes it from sibling tools like data_overheid_datasets_search which returns lists.

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 after obtaining an ID, but does not explicitly state when to use versus alternatives. For a simple retrieval tool, the context is clear enough, but lacks explicit 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 already include readOnlyHint and openWorldHint. Description adds context about search behavior but does not disclose pagination, rate limits, or result format beyond schema. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no wasted words. Every sentence provides actionable guidance.

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?

Adequate for a search tool with rich schema and annotations. Lacks description of return format or pagination behavior, but outputFormat parameter covers format. Could be more complete regarding result set handling.

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 only 20%, but description adds value by emphasizing keyword style and naming two key filters (organization, theme). However, most parameters remain undocumented in both schema and description, 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?

Description clearly states it searches the Dutch national open data catalog, with specific advice on using concise keywords. Differentiates from sibling tools like data_europa_datasets_search and data_overheid_dataset_get.

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 advises using concise topic keywords and combining with 'organization' or 'theme' filters. Does not explicitly mention when not to use or alternative tools, but the guidance is clear and actionable.

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 and openWorldHint, indicating safe read-only operation and possible partial results. The description adds no further behavioral details, which is acceptable given the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no wasted words. Every word contributes to understanding what the tool does.

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 is minimal but sufficient for a zero-parameter listing tool. It does not describe the return format, but with openWorldHint and no output schema, this is acceptable.

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?

There are no parameters, so schema coverage is 100%. The description correctly avoids extraneous detail. Baseline for zero parameters is 4.

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 lists 'all publishing organizations' on a specific domain, using a specific verb and resource. It distinguishes from sibling tools like data_overheid_datasets_search and data_overheid_themes.

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 the tool is for getting a list of all organizations. No explicit when-not or alternative guidance, but the zero-parameter nature makes it self-explanatory as a basic listing tool.

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 and openWorldHint. The description adds the claim of returning 'all' themes, which is a behavioral trait. However, no information about pagination, ordering, or exhaustiveness is provided. The description adds some value beyond annotations but is limited.

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 concise sentence that directly states the tool's purpose. No unnecessary words or information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, read-only, open world), the description is mostly complete. It covers the core purpose. However, since there is no output schema, the description could have provided a hint about the return format (e.g., list of strings or objects). Still, it is adequate for typical 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?

There are zero parameters, so the description does not need to add parameter information. The baseline for 0 parameters is 4, and the schema coverage is 100% (empty schema). The description adds no parameter semantics, but none are needed.

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 ('List') and a clear resource ('all dataset themes/categories'). It uniquely identifies this tool's function among siblings (e.g., data_overheid_datasets_search, data_overheid_organizations), which are focused on searching datasets or retrieving organizations.

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 as a simple lookup for themes/categories, but it does not explicitly state when to use this tool versus alternatives (e.g., before searching datasets with a theme filter). No exclusions or prerequisites are mentioned.

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 and openWorldHint. The description adds value by explaining the dimension exploration mode, which is a non-obvious behavior. No contradictions. The description is consistent with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with only two sentences, front-loading the purpose and data source. Every sentence adds value 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?

Given the tool has 12 parameters and no output schema, the description covers the key aspects (main filters and dimension mode) but lacks details on pagination, output formats, and error behavior. It is adequate for basic usage but could be more 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 50%, so the description partially compensates by grouping the main filter parameters (region, crime type, period) and explaining the dimension parameter. However, it does not add detailed semantics for parameters like top, limit, offset, or outputFormat, which remain only 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?

The description clearly states the tool searches Dutch registered crime statistics from a specific data source, and specifies the filtering by region, crime type, and period. It distinguishes itself from sibling tools by naming the exact data source and scope.

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 guidance on when to use the tool (searching crime statistics with filters) and mentions an alternative mode (exploring dimension values). However, it does not explicitly state when not to use it or list alternatives among 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 declare readOnlyHint and openWorldHint. The description adds behavioral details such as the need for an API key, the dataset parameter format, and the return structure (period, value, unit). No contradictions; adds value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two concise sentences. The first covers purpose and examples, the second covers parameter usage and requirements. It is efficient but could be slightly more front-loaded with the most critical info.

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 5 parameters (1 required), existing annotations, and no output schema, the description covers purpose, key requirement, parameter format, and return structure. It points to DNB API documentation for more details. Missing explicit error handling or rate limits, but adequate for a 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?

Schema description coverage is 80%. The description clarifies the dataset parameter format (pass as path or full URL), which adds slight value. Other parameters are adequately described in the schema, so the description provides minimal additional meaning.

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 it fetches datapoints from the DNB Statistics API, lists specific data types (interest rates, exchange rates, etc.), and specifies the return structure (period, value, unit). This differentiates it from sibling tools which are other Dutch government data APIs.

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 usage guidance: it mentions the required API key (DNB_API_KEY) and how to pass the dataset parameter. However, it does not explicitly contrast with alternatives or state when not to use this tool.

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 (readOnlyHint, openWorldHint) are consistent. Description adds critical context: 'Discovery-only search', 'Returns metadata only (id, titel, type, bevoegd gezag, geldigheidsdatums, viewer-link), geen juridische tekst'. This goes beyond the annotations to specify exactly what the tool does not return.

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 concise sentences: first identifies the tool and its scope, second clarifies output and requirement. No redundant information, every sentence is substantive.

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 search tool with 5 parameters (none required) and no output schema, the description covers domain, output fields, and a constraint (API key). It lacks details on pagination or sorting, but the schema's 'rows' parameter hints at pagination. Overall adequate for an agent to understand the tool's purpose and output.

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 80% (high), so baseline is 3. The description does not elaborate on the parameters; the schema already provides descriptions for query, bevoegdGezag, documentType, typeBevoegdGezag. The description adds no extra parameter guidance beyond mentioning the API key requirement.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it's a 'Discovery-only search for DSO Omgevingsdocumenten' and lists specific document types (omgevingsplannen, etc.). The verb 'search' and resource 'DSO Omgevingsdocumenten' are distinct from sibling tools which are various other Dutch government data sources.

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?

Mentions prerequisite (DSO_API_KEY) and implicitly indicates this tool is for retrieving metadata of Omgevingsdocumenten under the Omgevingswet. Does not explicitly exclude alternatives, but sibling tools are so different in domain that there's little ambiguity.

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 indicate readOnlyHint=true and openWorldHint=true. The description adds no additional behavioral context, such as pagination behavior or output format effects. Given the annotations, a score of 3 is appropriate as the description adds minimal value beyond them.

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 concise with one sentence, examples, and a clear instruction. It is well-structured and front-loaded, but could be slightly more structured with bullet points.

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 complexity (7 parameters, no output schema), the description covers the basic purpose but lacks details on how to effectively use the many parameters. It is adequate for a simple search tool but incomplete for advanced usage.

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 14% (only 'query' has a description). The description repeats the query guidance but provides no information on other parameters like rows, limit, offset, dryRun, verbose, or outputFormat, which are left unexplained.

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 searches DUO open datasets using education keywords, which distinguishes it from sibling tools that are specific to particular datasets (e.g., duo_exam_results, duo_schools).

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 provides clear guidance on using education topic keywords with examples and a caution against full questions. However, it does not mention when to prefer this tool over other DUO-specific tools like duo_exam_results or duo_schools.

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 provide readOnlyHint and openWorldHint. The description adds no behavioral context beyond 'Search', which is consistent but offers no new information. No contradiction.

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 concise sentence with no wasted words. However, it could include more information (e.g., about 'top') without becoming verbose.

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 4 parameters (one undocumented), no output schema, and no explanation of return values or pagination. The description is too minimal to fully prepare an agent for correct 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?

Schema coverage is 0%, so the description must explain parameters. It mentions year, school, and municipality but omits the 'top' parameter (number of results). This leaves important functionality undocumented.

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 searches 'DUO exam result data' and specifies three filter dimensions (year, school, municipality). This distinguishes it from sibling DUO tools like duo_schools (school info) or duo_datasets_search (generic datasets).

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 querying exam results but provides no explicit guidance on when to use this tool versus alternatives (e.g., duo_schools for school data). No when-not or context clues 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 readOnlyHint=true and openWorldHint=true, so the description's 'Search' is consistent. The description adds a helpful behavioral note (avoid full questions), but doesn't elaborate on other traits. With annotations present, this is adequate but not exceptional.

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 with no waste. The first sentence front-loads the purpose, and the second adds concise usage direction. Every word 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 search tool with two parameters and no output schema, the description covers the core functionality and provides usage examples. It could be improved by briefly describing the output, but it is largely complete given the tool's low complexity.

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 50%: 'query' has a description with examples, while 'top' has no description. The description adds meaning for 'query' ('Use institution or program names') but does not mention 'top', leaving its purpose unexplained. The schema provides constraints for 'top' (default, min, max), but the description could compensate further.

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 searches a specific register (DUO RIO) using institution or program names. The verb 'Search' and specific resource name distinguish it from sibling tools like duo_datasets_search or duo_schools.

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 usage context: 'Use institution or program names' and warns against full questions. Examples in the parameter schema reinforce correct usage. However, no explicit alternatives or exclusions are mentioned.

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?

The description adds 'Search' which aligns with the readOnlyHint annotation, but beyond that it does not disclose any additional behavioral traits (e.g., pagination, result format, rate limits). The annotation already covers read-only and open-world intent, so the description contributes minimal additional transparency.

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 with no filler. Every word is informative, and the purpose is front-loaded. Ideal conciseness.

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 output schema and four parameters (none required), the description lacks detail on return format, data variability, or field meanings (e.g., school type values). A search tool without output schema needs more context for effective 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?

With 0% schema description coverage, the description adds meaning for three of four parameters (name, municipality, type) but omits 'top'. This partially compensates for the schema gap, but incomplete parameter coverage limits the score.

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 searches DUO school data by three specific fields: name, municipality, or school type. It effectively distinguishes it from sibling tools, none of which target school 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 description implies use for school data searches but does not specify when to prefer this tool over alternatives, nor does it provide any exclusion criteria or use-case constraints.

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 indicate readOnlyHint=true and openWorldHint=true, which the description aligns with by stating it is a lookup operation. The description adds useful behavioral context: it lists the specific data returned (energy class, dates, building type, BAG ids, energy indicators) and mentions the API key requirement. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two sentences that are front-loaded with the tool's purpose and return values. Every sentence provides essential information without redundancy or fluff.

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 complexity (7 parameters, no output schema), the description covers the key aspects: purpose, return data, query methods, and API key requirement. It does not detail all possible response fields, but the listed categories are sufficient for an agent to understand what to expect. The lack of an output schema is somewhat mitigated by the clear description.

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 has 86% description coverage, which is high. The description gives an overview of query methods but does not add significant detail beyond the schema's parameter descriptions. For example, it notes that postcode requires huisnummer unless bagId is given, which is already present in the schema. Therefore, the description adds marginal value over 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 clearly states the tool's purpose: looking up registered energy labels for Dutch addresses from EP-Online. It specifies what is returned (energy class, dates, building type, BAG ids, energy indicators) and the two query methods (postcode+huisnummer or BAG id). This distinguishes it from sibling tools that focus on other Dutch address or government 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 description provides clear guidance on when to use the tool (to retrieve energy label information) and how to query (by postcode+huisnummer or BAG id). It also notes the required API key. However, it does not explicitly state when not to use it or suggest alternatives among the many sibling tools, though the specificity of the tool makes this less critical.

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=true and openWorldHint=true, so the description need not restate these. The description adds that it fetches a 'preview', suggesting a limited sample, but does not elaborate on the behavior (e.g., that it returns a subset, or how the preview is generated). The 'rows' parameter with max 200 is in the schema but not mentioned in the description.

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 conveys the core functionality and optional filtering. Every word is necessary, and there is no redundancy or fluff. It is appropriately concise for a straightforward tool.

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 is too brief for a tool that returns data with no output schema. It does not describe the return format, what constitutes a 'preview', or how the results are structured. Given the complexity of nested 'filters' and the lack of output schema, more information is needed for an agent to use it effectively.

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?

With 0% schema description coverage, the description must compensate. It explains 'dataset' (dataset code) and 'filters' (dimension values) but omits the 'rows' parameter entirely. Thus, it adds partial but incomplete semantic value 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 clearly states the action ('Fetch preview observations'), the resource (Eurostat dataset), and the identifier (dataset code). It also distinguishes the tool from its sibling 'eurostat_datasets_search' which is for searching datasets, not fetching previews. The optional filtering by dimension values is explicitly mentioned.

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 dataset code is known and a preview is needed, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites (e.g., having a dataset code from a search). No exclusions or when-not-to-use context is 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 provide readOnlyHint=true and openWorldHint=true. The description only states 'Search', which is consistent but adds no additional behavioral traits beyond what annotations convey. Since the bar is lower with annotations, but description contributes nothing new, score is 2.

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 is perfectly concise. It conveys the core purpose without any extraneous words. Every word 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?

Given the tool has 2 parameters, no output schema, and annotations cover readOnly and openWorld, the description is minimal. It lacks details on result format, how to refine searches, the role of the 'rows' parameter, or any limitations. While it provides the basic purpose, it is incomplete for effective use in all scenarios.

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 has 2 parameters: 'query' (required, string with examples) and 'rows' (optional, integer, no description). Schema description coverage is 50%. The description does not mention parameters at all, thus fails to add meaning or compensate for the undocumented 'rows' parameter. Baseline 3 reduced due to lack of compensation.

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 verb 'Search', the resource 'Eurostat for EU statistics datasets', and the method 'by topic keywords'. It is specific and distinguishes this tool from siblings like 'data_europa_datasets_search' by explicitly naming Eurostat. High clarity.

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 does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for Eurostat data through the name, but no explicit context, exclusions, or alternatives are given. Sibling tools exist for other data sources, but the description does not help the agent differentiate.

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 declare readOnlyHint and openWorldHint; the description adds the requirement for an API key but does not explain the return format, pagination, or how the list connects to other tools.

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 with no extraneous information, front-loading the action and resource.

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?

While the tool is simple, the lack of output schema and any description of the return format leaves ambiguity about what information the agent will receive to use subsequent tools.

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?

With zero parameters and 100% schema coverage (empty schema), the description adds no parameter detail, which is acceptable per the baseline for 0 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 states the verb 'List' and the resource 'available KNMI weather datasets', distinguishing it from sibling tools like knmi_latest_observations and knmi_warnings.

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 that this tool is a starting point to discover datasets, but does not explicitly state when to use it versus alternatives like knmi_search_datasets or how it relates to other KNMI 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 declare readonlyHint=true and openWorldHint=true. The description adds the API key requirement, which is useful for behavioral understanding, but does not disclose other traits like rate limits or data freshness.

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 sentence, front-loaded with purpose. Efficient but lacks parameter details; still earns a 4 for conciseness without excessive brevity.

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 one parameter and no output schema, the description should include parameter semantics and usage context. It fails to do so, leaving the agent underinformed.

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 single parameter 'top' has no description in either the input schema (0% coverage) or the tool description. Its meaning and purpose are entirely unclear, forcing the agent to guess.

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 gets recent earthquake data from KNMI, with a specific verb ('get') and resource ('recent earthquake data'). It is distinct from sibling tools like 'knmi_latest_observations' which focus on weather 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?

No guidance on when to use this tool vs alternatives. Only mentions a prerequisite (requires API key) but does not specify context or alternatives.

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: true and openWorldHint: true, establishing the tool as a safe read operation. The description adds the requirement for an API key, which is behavioral context beyond the annotations. However, no other behavioral traits (rate limits, data freshness, error handling) are disclosed.

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 short sentences, each serving a purpose: stating the function and noting the API key requirement. It is concise with no redundant information, though it could be slightly more informative without losing brevity.

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 no output schema, so the description should hint at return structure or format, but it does not. With 3 parameters and only one required, the description omits context about how the datasetName relates to KNMI datasets or what 'latest' implies. This leaves the agent with incomplete information for effective 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?

Schema coverage is only 33% (only datasetVersion has a description). The description does not explain the 'top' or 'datasetName' parameters, nor their meaning or usage. With low schema coverage, the description should provide additional parameter context but fails to do so.

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 'Get latest data files from a specific KNMI dataset', which specifies verb and resource. It distinguishes from sibling tools like knmi_latest_observations and knmi_search_datasets by focusing on 'data files' rather than observations or dataset metadata.

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 only mentions 'Requires KNMI_API_KEY' as a prerequisite but provides no guidance on when to use this tool versus alternatives. There is no indication of when to use knmi_latest_files over knmi_datasets or knmi_latest_observations.

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 and openWorldHint. Description adds the API key requirement, which is useful authentication context. No other behavioral traits (rate limits, output format) are mentioned, but basic safety is covered by annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, no wasted words. First sentence states purpose, second adds a necessary prerequisite. Front-loaded and efficient.

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?

Tool is simple but lacks output schema. Description doesn't explain what the observation files contain, their format, or how to handle the response. For a tool with many siblings and no output schema, more context is needed for correct 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?

Schema coverage is 0% with no parameter descriptions. Description does not explain the 'top' parameter's meaning (e.g., number of observations to return). It should compensate for the missing schema descriptions but fails to do so.

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 clearly states verb 'Get' and resource 'latest KNMI weather observation files', distinguishing from siblings like knmi_earthquakes or knmi_warnings. However, it doesn't explicitly differentiate from knmi_latest_files, which could also be for files. Sibling differentiation is vague.

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?

No guidance on when to use this tool vs alternatives like knmi_datasets or knmi_search_datasets. Lacks any when-to-use or when-not-to-use context.

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=true and openWorldHint=true, so safety is clear. Description adds the authentication requirement (API key), which is useful. No other behavioral details (rate limits, error handling) are mentioned.

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 with no wasted words. Front-loaded: first sentence states purpose, second adds prerequisite. Efficient and clear.

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 output schema and many sibling tools, the description does not explain what the search returns (e.g., list of dataset IDs, metadata). Lacks context for integrating results with other tools like knmi_datasets or knmi_latest_files.

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?

Single parameter 'query' has 0% schema description coverage. Description says 'by keyword' which provides basic semantics but lacks format constraints, allowed values, or examples. The description partially compensates but is insufficient.

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?

Clear verb 'Search' and resource 'KNMI weather datasets'. Distinguishes from sibling tools like knmi_datasets (which likely lists all datasets) and knmi_earthquakes by specifying keyword-based search.

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?

States requirement for KNMI_API_KEY but provides no guidance on when to use this tool versus alternatives (e.g., knmi_datasets or knmi_latest_observations). No when-not-to-use or context for selection.

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=true and openWorldHint=true. The description adds only the API key requirement, which is a prerequisite, not behavioral context. No additional traits such as rate limits or error handling are disclosed.

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 concise (two sentences) and front-loaded with the key purpose. However, it omits parameter semantics, which would add valuable information without much bloat.

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 tool with one optional parameter and clear annotations, the description covers the basic purpose and a requirement. However, it lacks parameter explanation and usage guidance, leaving gaps for an AI 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?

The input schema defines a single parameter 'top' with default and bounds, but the description provides no explanation of its meaning or purpose. With 0% schema description coverage, the agent is left to guess that 'top' limits the number of warnings.

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 action ('Get'), the resource ('current KNMI weather warnings'), and the scope ('for the Netherlands'). It is specific and distinguishes from sibling tools, such as knmi_earthquakes or knmi_latest_observations.

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 mentions a prerequisite ('Requires KNMI_API_KEY') but provides no context on when to use this tool versus alternatives like knmi_datasets or knmi_latest_observations. No guidance on when not to use it.

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 provide readOnlyHint and openWorldHint, so the safety profile is clear. The description adds minimal extra detail beyond the basic fetch operation, not contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise two sentences, front-loaded with verb and resource. Every word serves a purpose with no unnecessary detail.

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?

Adequate for a simple fetch tool, but lacks output format description. With no output schema, the agent cannot infer the return structure, leaving a gap.

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 0%, so description must compensate. It gives examples for component (e.g., NO2, PM10) but provides no explanation for rows parameter, leaving it under-documented.

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 fetches latest air quality measurements from Luchtmeetnet, with optional filtering by component. It is distinct from the diverse sibling tools, though 'latest' could be more specific.

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?

No guidance on when to use this tool versus alternatives or when not to use it. The description only mentions optional filtering, lacking explicit context for selection.

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 declare readOnlyHint=true and openWorldHint=true, covering safety and variability. The description adds limited behavioral context, only reinforcing that this is a search tool without detailing request/response behavior or limitations.

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 concise sentence with no filler, directly stating purpose and usage hint. It is front-loaded and efficient.

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 simple search nature, the description adequately states the scope but lacks details on return format, pagination, or result interpretation, which would be helpful given no output schema.

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 50% (query described, rows not). The description provides query examples and usage tips, adding value beyond the schema's brief description, but rows parameter is not mentioned.

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 'Search NDW open traffic data (Dutch road network)' clearly specifies the verb (Search) and resource (NDW open traffic data), distinguishing it from siblings like rdw_open_data_search (vehicle data) and pdok_search (geodata).

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 advises using 'traffic topic or road keywords' and the parameter description cautions against full questions, but no explicit guidance on when to choose this tool over alternatives or when not to use it is provided.

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

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

Annotations already define readOnlyHint and openWorldHint. The description adds context about the data returned (capacity, volume, utilization, CO2), the endpoint, and the requirement of an API key. It does not contradict annotations and provides useful behavioral insight beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two sentences: the first clearly states the action and source, the second summarizes the output. It is concise, front-loaded with purpose, and contains no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description mentions the specific types of data returned (capacity, volume, utilization, CO2, forecasts) and the authentication requirement. Given the high schema coverage and clear output summary, the description is complete enough for an agent to use this tool effectively.

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 high (89%), with most parameters having descriptions in the schema. The description adds general context about the output but does not elaborate on individual parameter semantics beyond what the schema provides, so a 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 explicitly states it searches NED.nl for energy generation/consumption per source with examples (solar, wind, etc.). It mentions the specific endpoint '/v1/utilizations' and the returned metrics, clearly distinguishing it from sibling tools that cover other Dutch government 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 description implies usage for energy data queries and notes the API key requirement, but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or comparisons to sibling tools are provided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, which cover safety and external sources. The description adds that it searches for geospatial metadata, which is consistent. It does not contradict annotations, but does not provide additional behavioral details like pagination 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 one sentence and very concise. It communicates the key purpose without extraneous words. However, it could be slightly more informative without losing brevity.

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 search tool with two parameters and no output schema, the description covers the source and type of data. It is adequate but does not explain return value format or what to expect from results, leaving some 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 50%: only the query parameter has a description. The tool description does not add any information about the rows parameter (e.g., that it limits results). The query parameter examples are helpful but already 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?

The description clearly states the tool searches Nationaal GeoRegister for geospatial metadata, including maps and WMS/WFS services. It specifies the resource (NGR) and the type of content, distinguishing it from sibling tools that search other Dutch government 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 description says to use spatial data topic keywords, which gives a usage hint. However, it does not explicitly state when to use this tool versus alternatives like bag_address_detail or cbs_tables_search. The context is implied but not formally guided.

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 provide readOnlyHint and openWorldHint. Description adds context about language support and routing behavior but does not disclose rate limits, error handling, or details on source selection. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load the purpose. No wasted words, but could be slightly more structured (e.g., list key features).

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 high parameter count and many sibling tools, the description is too sparse. It does not explain output format, how parameters affect routing, or handling edge cases. Lacks guidance for effective 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?

Schema description coverage is 0%. Description only mentions temporal expressions but does not explain the 9 parameters (top, limit, dryRun, etc.) which are left completely undocumented. This is a major gap for a tool with many 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 states it is a smart router for natural-language questions about Dutch government data, and it queries the most relevant source(s). This differentiates it from sibling tools that target specific data sources.

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 says 'Use this when the best source is unclear', providing clear guidance. Also mentions support for temporal expressions in Dutch and English, but does not give a comprehensive list of when not to use it or alternatives.

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=true and openWorldHint=true. The description adds that the tool requires an API key and is realtime. These are useful but still leave out potential behaviors such as rate limits, data freshness, or error handling. The description does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that packs essential information: purpose, operations, API versions, realtime nature, and authentication requirement. It is front-loaded and concise, though adding bullet points might improve readability for the many operations.

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 4 operations and no output schema. The description only says 'live train info' without describing the return format or what data each operation provides. For a tool with multiple operations, this is insufficient guidance on what the output will contain. More details on response structure or examples would aid completeness.

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 86%, so many parameters are already documented. The description adds value by clarifying the operation enum with Dutch translations and version numbers (v2/v3), and implies parameter requirements for different operations (e.g., 'trips' needs fromStation and toStation). This goes beyond the raw 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 clearly states it queries the NS Reisinformatie API for live train info, listing specific operations (disruptions, departures, arrivals, trips) with API versions. It is specific about the resource and verb. However, it does not explicitly differentiate from the sibling tool 'ovapi_departures' which also provides public transport departures.

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 mentions that the tool requires an API key and provides realtime data, giving basic context. However, it does not elaborate on when to use each operation or contrast with alternatives like 'ovapi_departures'. No explicit when-to-use or when-not-to-use guidelines are provided.

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

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

Annotations already indicate readOnlyHint and openWorldHint, which the description does not contradict. The description adds context about returned fields but does not disclose additional behavioral traits like pagination or rate limits.

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 that are front-loaded and concise. No unnecessary words, clearly stating purpose, filters, and return values.

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 9 parameters and no output schema, the description covers core purpose and returns but lacks guidance for many parameters. It is adequate but incomplete for a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% (3 of 9 parameters have descriptions). The tool description lists keywords, KVK, and treatment type as filters but does not describe top, limit, offset, dryRun, verbose, or outputFormat. It fails to compensate for the low 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 searches waiting times for a specific domain (Dutch hospital/medical-specialist care), lists filters (keywords, KVK, treatment type) and returned fields (provider, specialism, waiting time, reference date). It is distinct from sibling tools which cover different 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 description implies usage for querying waiting times with specific filters, but does not explicitly state when not to use it or mention alternatives. The context of many sibling tools suggests it is domain-specific, providing clear context.

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=true and openWorldHint=true. The description is consistent but adds no additional behavioral context beyond confirming it's a read operation.

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?

Single sentence with no unnecessary words, front-loading the key action and resource.

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 get-by-identifier tool, the description covers the core purpose. It lacks details on error handling or output, but the open world hint and simplicity make it sufficient.

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?

With 0% schema description coverage, the description only says 'by its identifier' which adds minimal context. The parameter name 'identifier' is self-descriptive, but no format or examples are provided.

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 action (Get), resource (specific official publication), and method (by its identifier). It distinguishes itself from sibling 'officiele_bekendmakingen_search' which handles searching.

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 you have a specific identifier, and search is for when you don't. However, it does not explicitly state when not to use or mention alternatives.

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=true (safe read) and openWorldHint=true (possible broad results). The description adds that it searches multiple publication types and allows filtering, but it does not disclose pagination behavior, what happens on no results, or the nature of the search algorithm. The behavioral transparency beyond annotations is moderate.

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 tool's purpose and key usage instructions. It is concise and contains no unnecessary words. However, given the complexity of 12 parameters, it could be more efficient by listing parameter functionalities in a structured way.

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?

Despite having annotations, the description fails to cover many aspects of the tool's behavior and parameters. With 12 parameters and no output schema, the description should explain pagination (top, limit, offset, startRecord), the meaning of dryRun and verbose, and output format options. The current description is too sparse for a complete understanding.

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 adds meaning for three filter parameters (type, authority, date range) by mentioning them explicitly. However, with schema coverage only 8% (only query described), the description should explain many other parameters like top, limit, offset, dryRun, verbose, outputFormat, which are left unexplained. This is insufficient for an agent to use the tool correctly.

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 searches Dutch official publications and lists specific types (Staatscourant, Staatsblad, etc.). The verb 'Search' and resource 'Officiële Bekendmakingen' are explicit. However, it does not differentiate from siblings like 'wetten_bwb_search' or 'overheid_api_register_search', though the listing of publication types provides some distinction.

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 advises using legal/policy topic keywords and mentions optional filters (type, authority, date range). This gives some context for when to use the tool, but there is no explicit guidance on when not to use it or alternatives. For example, if one needs a specific record, 'officiele_bekendmakingen_record_get' would be more appropriate, but this is not mentioned.

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=true and openWorldHint=true. The description adds no behavioral details beyond that, such as pagination, rate limits, or response format. With annotations present, this is acceptable but not exceptional.

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 concise sentences that immediately convey purpose and key usage tips. No redundant or irrelevant 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?

Covers the main usage aspects for a search tool with 4 parameters and no output schema. Could mention pagination behavior or typical result structure, but overall sufficient given the presence of annotations and clear purpose.

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 50% (query and sort have descriptions). The description reinforces the schema by advising 'policy topic keywords' for query and 'sort for recency'. It does not clarify the undocumented 'bestuurslaag' parameter. Adds some value but does not fully compensate for the coverage 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?

Clearly states the tool searches Open Raadsinformatie (ORI) for Dutch municipal council documents, motions, and decisions. Distinguishes from sibling tools that cover other Dutch government data sources like official publications (officiele_bekendmakingen_search) or national parliament (tweede_kamer_search).

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 guidance: use policy topic keywords and the sort parameter for recency. However, it does not explicitly state when not to use this tool versus siblings like officiele_bekendmakingen_search or tweede_kamer_search.

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 set readOnlyHint=true (safe read) and openWorldHint=true (data may change). The description adds that it returns realtime departures and lists fields, but does not disclose any side effects, rate limits, or data freshness details. The behavioral traits are adequately covered by annotations with moderate added context.

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 purpose and input requirement, then output fields. Every sentence adds value without waste. 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?

Given there are 8 parameters (1 required) and no output schema, the description is incomplete. It only explains the required parameter (timingPointCode) and lists return fields but fails to document pagination (top, limit, offset), dryRun, verbose, or outputFormat. The output structure is not fully described, leaving gaps 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?

Schema description coverage is low (25%), with only timingPointCode and line having descriptions. The description adds meaning for timingPointCode (required, example, lookup instructions) but ignores other parameters like top, limit, dryRun, offset, verbose, outputFormat. The schema provides defaults but no descriptions, so the description fails to compensate for the low 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 provides realtime public transport departures for a Dutch stop, listing the required input (timingpointcode) and the output fields (line, destination, times, delay, status). It differentiates from siblings like ns_reisinformatie by covering tram/bus/metro/ferry and specifying the source (OVapi).

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 requirement for a timingpointcode, provides an example (32002646), and tells the user where to look it up (9292 or OVapi/GTFS index). It warns not to pass a stop name. However, it does not mention when to avoid this tool or alternatives for other transport modes.

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?

Adds that an API key is required, which is not covered by annotations. The readOnlyHint is consistent with 'search' behavior. No contradictions.

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 concise, front-loaded sentences with no wasted words. Essential information is prioritized.

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 absence of output schema, the description does not specify return values. However, the tool's purpose is clear and the parameter details are mostly self-explanatory. Slightly incomplete but 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?

The description adds useful context for the 'query' parameter (examples, prohibition of full questions) but does not explain other parameters like top, limit, offset, dryRun, verbose, or outputFormat. Schema coverage is low (14%), so the description partially compensates.

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 searches the Dutch government API register using API/data topic keywords, distinguishing it from sibling tools like data_overheid_datasets_search which search datasets.

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 examples of valid queries and warns against passing full questions, but does not explicitly state when not to use this tool or suggest alternative 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 declare readOnlyHint and openWorldHint. The description adds value by specifying returned fields (name, type, TOOI URI, etc.) and the enrichment behavior. No contradictions.

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 with no wasted words. Purpose, output, and utility are front-loaded. Efficient and clear.

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 9 parameters and no output schema, the description is somewhat sparse. It lists returned fields but does not describe the response format or structure. More detail on output would improve completeness.

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 low (33%). The description mentions 'query' and 'enrich' briefly but does not explain most parameters. Enrich auto-skip is noted, but top, limit, dryRun, offset, verbose, outputFormat remain undocumented.

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 searches a specific register (ROO/TOOI) for Dutch government organizations by name, lists returned fields, and explains its utility. It is distinct from siblings which cover other 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 description implies usage for finding government organizations and linking cross-source data. It does not explicitly state when not to use it or alternatives, 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 and openWorldHint, so the description need not cover those. However, it adds no additional behavioral details such as rate limits, pagination, or response format, which would be helpful given the lack of 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 extremely concise: two short sentences that immediately state the action and provide examples. No wasted words.

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 search tool with no output schema, the description fails to mention expected return values or result structure. While the openWorldHint implies flexibility, additional completeness would help agents understand what to expect from the response.

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 adds examples to the 'query' parameter (e.g., 'Damrak 1 Amsterdam') beyond the schema, but does not mention the 'rows' parameter. With 50% schema coverage, the description partially compensates but could be improved.

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 searches the PDOK Locatieserver for Dutch addresses and locations with a specific verb and resource. It distinguishes from sibling tools by focusing on general address/location search rather than specific datasets.

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 basic usage guidance ('Use specific address strings or place names') but does not explicitly state when not to use this tool or compare it to alternative sibling tools like bag_address_detail or bag_lookup_address.

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 and openWorldHint. The description adds value by explicitly stating that only SELECT queries are permitted and that LIMIT is capped, which are behavioral constraints not fully covered by annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences that are front-loaded, containing no wasted words. Every sentence adds essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a SPARQL query tool and the absence of an output schema, the description is adequate but lacks details about the return format (e.g., SPARQL JSON results). This gap may hinder an agent from correctly parsing the response.

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 0%, so the description must compensate. It only vaguely mentions 'SPARQL SELECT query' and 'LIMIT is capped', leaving the 'query' parameter unexplained in terms of format, syntax, or expected values. This is insufficient for an agent to correctly formulate a query.

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 executes a read-only SPARQL SELECT query on RCE cultural heritage linked data, specifying allowed query type and constraint (LIMIT capped). This distinguishes it from the sibling 'bag_linked_data_select' tool, which targets a different dataset.

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 querying RCE linked data and notes that only SELECT queries are allowed, but it does not explicitly provide when-to-use or when-not-to-use guidance compared to alternatives like bag_linked_data_select or other search 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?

The description adds useful behavioral context beyond the readOnlyHint and openWorldHint annotations by detailing search modes and providing example query formats. However, it does not disclose potential rate limits, error states, or restrictions.

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 concise at two sentences, with no redundancy. It front-loads the main purpose and immediately provides practical examples.

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 covers the basic search functionality but omits the return format and does not explain the 'rows' parameter's role in pagination. Given the tool's simplicity and presence of annotations, it is adequate but has gaps.

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?

With schema description coverage at 50%, the description adds value for the 'query' parameter by listing example formats and clarifying license plate lookups. However, the 'rows' parameter receives no explanatory text, leaving its purpose ambiguous.

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 searches RDW open vehicle data (Dutch vehicle registry) and specifies two search modes: by license plate or keywords. This provides a specific verb-resource pair and distinguishes it from sibling tools focused on other Dutch data sources.

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 vehicle data queries but gives no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or provide criteria for selecting among 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 indicate readOnlyHint and openWorldHint. Description adds behavioral context about query sensitivity and parameter usage, but does not significantly expand beyond what annotations provide.

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?

Extremely concise with two clear sentences. No redundant information; every sentence adds value.

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 search tool with well-described schema and no output schema, the description provides key usage context. It covers how to use parameters effectively, fulfilling completeness for this complexity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.