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

No annotations are provided, so the description carries the full burden. It describes the tool as an informational overview, implying a read-only, non-destructive operation, but it does not explicitly state side-effect-free behavior or data freshness. Since it is a reference tool, this is adequate but could be more explicit.

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, concise sentence that front-loads the core purpose and immediately references the relevant sibling tools. Every word adds value, with no redundancy.

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

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

Given the tool has no parameters and an output schema exists (which defines return values), the description sufficiently explains what the tool provides. It names the two tools whose codes it covers, which is the key contextual information. The only minor gap is not stating whether the data is static or dynamic, but this is not critical for a reference 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?

The tool has zero parameters, so the schema fully covers them (100% coverage). Per the rubric, the baseline for 0 params is 4, and the description adds no param-specific meaning, which is appropriate since there are none.

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 an overview of consulted sources and the list/group codes used by two specific sibling tools (`soorten_in_gebied` and `lijst`). It identifies a specific resource and its purpose, distinguishing it from the query-focused siblings. The verb 'Overzicht' (overview) is explicit.

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 need codes for the named tools, consult this. However, it does not explicitly state when to use it vs. alternatives, nor does it provide exclusions or prerequisites. The context is clear but not prescriptive.

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It reveals the fixed template structure, the two search radii and their rationale, the map behavior (including the bwk_kaart option), the licensing nuance (ook_niet_commercieel default and when to set False), and even linguistic constraints ('nooit van zwaar of zwaarst beschermd'). It also instructs to base the summary only on the response. This is thorough and transparent.

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?

Although long, the description is well-structured and every sentence earns its place. It front-loads the core purpose and usage triggers, then explains the template, search radii, maps, post-action summary, and finally the parameters. There is no redundancy or filler; the Args list is clear and matches the schema properties.

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 13 parameters and no output schema, the description covers all parameters, the full behavior (template, maps, licensing), and the post-action requirements. It even addresses edge cases like sharing vs. internal use (ook_niet_commercieel) and language precision. Nothing critical is missing for an agent to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate entirely. It does so with an Args section that explains every parameter: adres (with fallback to lat/lon), pad (with default path), straal_soorten_m and straal_gebieden_m (with defaults and rationale), jaar_van/jaar_tot, kaarten, bwk_kaart, detail_soorten, bewaar_kaarten, and ook_niet_commercieel (with licensing meaning). This adds meaning far 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 opens with a specific verb and resource: 'Maak in één stap het vaste DATARAPPORT NATUUR als PDF voor een projectlocatie.' It also names the exact user triggers ('datarapport, natuurrapport, bronnenscan of "rapport zoals het vorige"'), which clearly differentiates it from sibling tools that handle individual queries like zoek_soort or waarnemingen. The purpose is unambiguous and distinct.

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 when to use the tool: 'Gebruik deze tool wanneer de gebruiker om een datarapport, natuurrapport, bronnenscan of "rapport zoals het vorige" vraagt.' It also provides post-action guidance on how to summarize results and which terminology to use. However, it does not explicitly mention when NOT to use it or name alternative tools for other cases, so it's slightly short of a 5.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It lists the output fields but does not state that this is a read-only operation, whether authentication is required, or whether any side effects occur.

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 short and front-loaded, with one sentence explaining the tool's purpose and one argument definition. There is no redundant wording or 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?

For a single-parameter metadata lookup with an output schema present, the description covers the essential input semantics. It could be improved with an explicit read-only note or usage pointer, but the simplicity of the tool makes the current text largely 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 compensates by defining `dataset_key` as a GBIF-dataset UUID and indicating it can come from `per_dataset` or an observation. This adds format and provenance context beyond the schema's plain string type.

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

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

The description clearly states that the tool provides provenance metadata—origin, publisher, license, DOI, and citation—for a GBIF dataset. It lacks an explicit verb such as 'returns' or 'retrieves', but the resource and content are specific enough to distinguish it from observation, species, and area-related 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 parenthetical '(uit `per_dataset` of een waarneming)' helps explain where the dataset key comes from, but the description does not explicitly say when to use this tool versus alternatives. Usage is implied through the clear purpose rather than stated directly.

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?

With no annotations, the description carries the full behavioral burden. It thoroughly discloses file naming conventions, the second records file when met_records=True, JSON metadata contents, dataset-column notation, licensing defaults, and the distinction between source dataset and validation status.

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 long but well organized: purpose and output behavior come first, followed by dataset-split details and an Args section. Each section adds necessary information for a complex export tool, and the most decision-relevant facts are 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 description is complete for output format, metadata, licensing, and dataset splitting, but it does not explain return values despite having no output schema. It also delegates the full filter semantics to soorten_in_gebied and leaves several parameters undocumented, which creates gaps for an agent without access to that sibling's 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?

Only three parameters (pad, met_records, ook_niet_commercieel) are explained in the Args section. With 14 parameters and 0% schema description coverage, the remaining geospatial and filter parameters are left to their schema titles and the generic reference 'Zelfde filters als soorten_in_gebied', which is insufficient compensation for such a large parameter set.

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 opens with a specific verb and resource: 'Schrijf een volledige gebiedsbevraging weg als CSV of JSON'. It clearly identifies the output formats, optional records, metadata, and the report-oriented purpose, which distinguishes it from sibling query tools like soorten_in_gebied.

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 intended use ('Bestemd voor datarapporten') and ties the filters to the sibling tool soorten_in_gebied. It also gives conditional guidance for met_records and ook_niet_commercieel, but it does not explicitly say when not to use this tool or compare it directly with 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?

With no annotations provided, the description carries the full burden and does well: it explains the selection logic (overlap first, then nearest within radius), distance in Lambert 72, error handling via 'niet_geraadpleegd', and that a layer with an error is not 'geen gebied'. It also discloses data sources and geographic 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 lengthy but information-dense and well-structured: it opens with a clear purpose, then explains behavior, sources, and parameters in logical sections. It front-loads the core functionality and avoids redundancy, though some sentences could be tightened.

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

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

Given the tool's complexity (7 parameters, multiple layers, error states, geographic restrictions) and the presence of an output schema, the description is highly complete. It covers purpose, behavior, parameter semantics, and edge cases (error status, only Flanders), leaving little ambiguity for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must explain parameters—and it does thoroughly. It clarifies 'adres' can be an address, lat/lon, or WKT (with coordinate system), defines 'straal_m', lists valid 'lagen' codes with examples, and explains 'max_treffers_per_laag' sorting. All seven parameters are covered with added 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 explicitly states the tool returns protected areas and area statutes around a point or polygon, enumerating a detailed list of layer types (Natura 2000, VEN/IVON, etc.). It clearly defines the query behavior (overlap vs. nearest within radius) and geographic scope, making it distinct from sibling tools.

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

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

The description provides contextual constraints (only Flanders) and input flexibility, but does not explicitly compare with sibling tools or state when this tool is preferred over alternatives like 'kaart_gebieden' or 'soorten_in_gebied'. Usage guidance is implied rather than stated.

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?

There are no annotations, so the description carries the burden of behavioral disclosure. It does reveal that an external Digitaal Vlaanderen geolocation service is used and that output includes coordinates and municipality, but it does not mention potential failure modes, coverage limits, or whether network/auth requirements exist.

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 compact and front-loaded: the core purpose and source are in the first line, followed by a minimal parameter example block. No unnecessary filler is present.

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 an output schema present, the description does not need to document return fields in detail. It covers input scope, accepted input forms, and output type well enough for a simple one-parameter geocoding tool.

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

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

Schema coverage is 0%, so the description must clarify the 'adres' parameter. It does so with two concrete examples covering both a full address and a place name, which is sufficient for a single free-form string 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 defines a geocoding transformation from an address or place name in Flanders/Brussels to WGS84 coordinates and municipality, and it names the underlying service (Digitaal Vlaanderen, geolocation v4). This is specific enough to distinguish it from all listed sibling tools, which are biodiversity-data related.

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

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

The intended use is clear: provide an address or place name in Flanders/Brussels. It does not explicitly list when-not-to-use or alternatives, but the scope is well delimited and the siblings are unrelated, so the context is sufficient.

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?

With no annotations provided, the description carries the full burden and does so strongly: it discloses the return value (file path plus legend with color, count, status), the meaning of `niet_geraadpleegd`, the fact that empty layers are omitted, the ±25% map-extent margin, and that `per_groep` returns a `kaarten` list. This goes well beyond what the schema tells the agent.

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 long but each sentence earns its place: purpose and output semantics are front-loaded, followed by per-parameter guidance and practical recommendations. There is no filler, and the structure mirrors the invocation workflow.

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 10 parameters, no annotations, and no output schema, this definition is exceptionally complete. It explains return fields, edge-case status values, file naming behavior, and when to change embedded options, giving the agent enough context to invoke it correctly in realistic report-generation 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?

Schema description coverage is 0%, so the description must compensate, and it does: every parameter is explained, including coordinate systems (WGS84 for adres/lat/lon/wkt, Lambert 72 for the map), file format constraints (.png/.jpg), pixel bounds (600-2400), and the dual role of `straal_m` as search radius and map cutoff. This fully compensates for the bare schema.

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

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

The description states a specific verb and resource: 'Tekent de gebieden uit `gebieden_rond` op de GRB-basiskaart van Digitaal Vlaanderen', producing a situational map with protected areas, legend, scale bar, north arrow, and search circle. It is clearly distinguished from data-returning siblings like `gebieden_rond` by framing itself as a situeringsfiguur for reports and notes.

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 gives intended use ('Bedoeld als situeringsfiguur in een datarapport of nota'), restricts use to Flanders, and gives concrete conditional recommendations: use .jpg for multi-map reports, disable the embedded legend for small reproductions, and use `per_groep` when the Biologische Waarderingskaart is included. It does not explicitly name exclusions among siblings, so it stops short of a 5.

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

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

No annotations are present, so the description carries the burden of behavioral disclosure. It documents filtering semantics such as case-insensitive text search, category filtering, and a max-results upper bound, which is useful. However, it does not mention error handling, filter combination behavior, or pagination, leaving moderate gaps.

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

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

The description is a single purpose sentence followed by a compact Args block, with no filler or repetition. It front-loads the main purpose and keeps each parameter explanation short and directly useful.

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 four-parameter retrieval tool with an output schema and no annotations, the description provides enough operational context: required code source, optional filters, and result cap. The main gap is the lack of when-to-use guidance, already penalized under usage guidelines, and the list of valid codes is only illustrative.

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%, and the description fully compensates by documenting all four parameters with concrete meaning and examples. `code` is linked to `bronnen`, `zoek` specifies searchable fields and case-insensitivity, `categorie` gives value examples, and `max_resultaten` is defined as an upper bound.

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 opening sentence clearly states the tool returns the contents of one authoritative species list and names concrete lists (Soortenbesluit, HRL-bijlagen, Rode Lijst, Unielijst). This makes resource and scope clear, but it does not explicitly contrast with sibling tools such as zoek_soort or soort_status, so differentiation is mostly inferred.

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 tells the agent that `code` comes from `bronnen` and gives example codes, but it never states when to prefer this tool over siblings or when not to use it. There is no mention of alternatives for searching species or checking statuses, so selection guidance is absent.

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

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

With no annotations provided, the description carries the full behavioral burden, and it delivers: the strict-to-less-strict protection sorting order, the completeness caveat ('volledig=False' when the time budget is exceeded, see 'ontbrekend'), the performance guarantee that per_dataset_per_soort costs no extra GBIF calls, and the licensing default behavior. It even warns to read 'waarschuwingen' and 'kanttekening', signaling failure modes upfront.

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 long, but the length is earned: 19 undocumented parameters and a complex domain leave little room for trimming. It is front-loaded with a concrete example query that makes the tool instantly scannable, and parameter names are code-formatted for navigation. The sorting-order and filter-group sentences are dense enough to require re-reading, which prevents a 5.

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 complexity (19 params, zero annotations, 12 siblings), the description is remarkably complete: use case, output fields, caveats, pagination, licensing, and sibling routing are all covered. Two minor gaps remain: no statement of precedence between the four area selectors (adres/wkt/gemeente/lat/lon) when multiple are supplied, and jaar_van/jaar_tot are only implicitly explained via the 'sinds 2020' example.

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 — and it covers nearly all 19 parameters with meaning beyond the schema titles: filter groups with their real-world semantics ('wat in een natuurtoets telt'), wkt orientation, straal_m's default, formaat's tradeoff with a concrete cutoff ('aanbevolen bij >50 soorten'), and behavioral consequences like max_onzekerheid_m triggering a recount. Only lat/lon lack explicit prose, but those are self-evident from 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 opening sentence states the exact query and enrichment: which species were observed in an area, linked to their protection and Red List status. It also actively distinguishes itself from siblings — 'Voor enkel aantallen: telling_in_gebied' and 'Doorklikken naar de records kan met waarnemingen(...)' — so an agent can tell them apart without opening their schemas.

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

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

The description opens with the canonical M.E.R./passende beoordeling scenario ('welke bijlage IV-soorten... binnen 750 m van dit perceel sinds 2020?') and gives explicit routing to alternatives: telling_in_gebied for pure counts, waarnemingen for record-level drill-down. It also gives a conditional rule for ook_niet_commercieel: keep the default for internal working documents, set False when the result will be shared or published.

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?

No annotations are present, so the description carries the full behavioral burden. It discloses the consulted registers, the output fields 'samenvatting' and 'vermeldingen', and the crucial caveat that absence from the lists is not a statement about actual legal protection status. This goes well beyond the 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 well structured: a lead summary, the authoritative sources, the output contract, and the usage caveat each earn their place. The parameter guidance is clearly separated and scannable.

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 single-parameter query tool, the description covers input formats, result semantics, source details, and the empty-result interpretation. An output schema exists)Skip, and the description explains return fields sufficiently for an agent to understand what will happen.

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%, but the 'Args' section specifies that 'soort' accepts a Dutch or scientific name, or a GBIF taxonKey. For a single string parameter, this gives the agent exactly the input alternatives it needs to invoke 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 opens with 'Beschermings-, Rode-Lijst- en exotenstatus van één soort in Vlaanderen/België' – a precise, resource-scoped statement. It clearly narrows the operation to a single species and to legal/red-list/invasive statuses, distinguishing it from sibling tools like 'waarnemingen' and 'soorten_in_gebied'.

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

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

It gives clear context: use this tool for authoritative protection, Red List, and invasive-species status with per-entry sources. It also adds an interpretation rule for empty 'vermeldingen'. It does not explicitly name alternative sibling tools, so it falls just short of full exclusionary 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?

No annotations are provided, so the description carries the full burden. It discloses performance behavior: `soorten_per_dataset=True` triggers ten parallel GBIF calls and adds ~2 seconds, and is off by default to keep the tool fast. It also discloses licensing behavior: `ook_niet_commercieel` defaults to True because output is an internal working document, and must be set to False for sharing/publishing. It also notes that `per_dataset` counts come 'gratis uit dezelfde facetbevraging'. These are meaningful behavioral traits beyond the schema. It doesn't mention error cases or rate limits, but the disclosed behaviors are substantial.

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 well-structured: a one-sentence summary, a short paragraph on the relationship to `soorten_in_gebied`, a paragraph on `per_dataset` and `soorten_per_dataset`, and a bulleted Args list. It is longer than the typical description, but every sentence earns its place by explaining behavior or usage. The front-loaded summary is excellent. It loses one point for being somewhat dense and for the Args section partially repeating parameter names that are already in the schema, but the added context justifies most of the length.

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 11 parameters, no annotations, and an output schema. The description covers the tool-specific parameters and the key behavioral trade-offs (speed, licensing). It also tells the agent what to do next (`soorten_in_gebied` for names). It doesn't explain the area parameters, but those are likely shared with `soorten_in_gebied` and are named clearly in the schema. Given the complexity and the lack of annotations, the description is quite complete. A 5 would require explicit coverage of the area parameters or a pointer to where they are documented; a 4 is appropriate.

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. It explains `filter` (list codes, default 'beschermd,rodelijst,invasief'), `soorten_per_dataset` (adds per-dataset counts, slower), and `ook_niet_commercieel` (license filtering, default True, set False for sharing). It also references `per_dataset` as a concept. However, the area parameters (lat, lon, wkt, adres, gemeente, straal_m, jaar_van, jaar_tot) are not explained in the description, though they are likely shared with `soorten_in_gebied` and the schema names are fairly self-explanatory. The description adds real meaning for the three tool-specific parameters, which is the most important part.

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 opens with a clear, specific question: 'Hoeveel beschermde, Rode-Lijst- en invasieve soorten zijn in een gebied gemeld — alleen aantallen, snel.' This states the verb (count/report), resource (protected, Red List, invasive species in an area), and the key constraint (counts only, fast). It also explicitly distinguishes itself from the sibling `soorten_in_gebied` by saying it returns counts and that `soorten_in_gebied` should be used for names. This is a strong purpose statement that differentiates it from siblings.

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 says 'Gebruik daarna `soorten_in_gebied` (bv. met filter='kern') voor de namen.' This tells the agent when to use this tool versus the sibling. It also explains when to set `ook_niet_commercieel` to False (when sharing/publishing) and when to enable `soorten_per_dataset` (when per-dataset counts are needed, with a cost/benefit note). This is explicit when/when-not guidance with 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?

With no annotations provided, the description carries the full disclosure burden and does so well: it reveals that waarnemingen is only a sample capped at 300 while totaal is the true count, explains pagination via offset, and warns that per_verificatiestatus counts only the returned records and that several sources don't fill identificationVerificationStatus ('(leeg)'). It also discloses the licensing default (output is an internal work document) and instructs the agent to read and carry over kanttekening into the advice. Minor gaps remain: no explicit read-only statement, rate limits, or error behavior.

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

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

The description is front-loaded with a one-sentence purpose, then proceeds through area modes, output semantics, caveats, and a compact Args reference. It is long, but the length is justified for a 13-parameter tool with zero schema descriptions; the only real redundancy is that area modes are explained both in the prose and again per-parameter in Args.

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 (13 parameters, no annotations, 0% schema coverage), the description is remarkably complete: it covers filtering, area modes, pagination, sampling limits, data-quality caveats, licensing, and the sibling workflow. Since an output schema exists, the description rightly focuses on behavior and parameters rather than return-value fields; remaining gaps are minor (error conditions, no-result behavior, rate limits).

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

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

Schema description coverage is 0%, so the description must fully compensate, and it does: the Args block documents all 13 parameters with formats, examples, constraints, and defaults (e.g., soort accepts a Dutch/scientific name or GBIF taxonKey; wkt gives a POLYGON in WGS84 lon lat; max_resultaten caps at 300). It also conveys cross-parameter constraints the schema cannot express, such as the four alternative area-specification modes and that dataset_key takes a UUID from per_dataset or the datasets field.

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 opening sentence states a specific verb+resource: 'Waarnemingen van één soort in een gebied en periode (GBIF, België)' — observations of one species in an area and period from GBIF Belgium. This immediately distinguishes it from sibling tools like soorten_in_gebied (species list per area) and zoek_soort (name resolution). The description even explains the click-through relationship to soorten_in_gebied's datasets field, further reinforcing the differentiation.

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

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

The description explains the four mutually exclusive area-specification modes (adres, lat/lon, wkt, gemeente) and the whole-Belgium default, telling the agent exactly how to form a query. It explicitly names a sibling workflow (dataset_key clicking through from soorten_in_gebied's datasets field) and gives license-usage guidance (set ook_niet_commercieel to False when sharing/publishing). However, it stops short of explicit 'use X instead of this tool' exclusions for the other 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?

Zonder annotaties draagt de beschrijving de volledige last. Het deelt de zoekvolgorde, waarschuwt voor ambiguïteit bij meerdere treffers en geeft aan dat het meerdere kandidaten kan retourneren. Dit is relevante gedragsinformatie die verder gaat dan een simpele definitie. Het mist details zoals foutafhandeling of snelheid, maar voor een lookup-tool is dit voldoende.

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?

De beschrijving is compact en gestructureerd: eerst het doel, dan het zoekpad en ambiguïteit, dan de parameters. Het is informatief zonder overbodige tekst. De structuur is logisch en de belangrijkste info staat vooraan. Een kleine korting omdat de zin over zoekvolgorde iets uitweidt over de INBO, maar dit is relevant.

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?

Er is een output-schema aanwezig, dus de beschrijving hoeft retourwaarden niet te beschrijven. De parameters worden goed gedocumenteerd en de tool is simpel genoeg (2 parameters). De waarschuwing over ambiguïteit is nuttig. Het is compleet genoeg voor een agent om de tool correct aan te roepen.

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?

De schema-beschrijvingsdekking is 0%, maar de beschrijving geeft concrete voorbeelden voor 'naam' ('vroedmeesterpad', 'Alytes obstetricans', 'Triturus') en legt 'max_resultaten' uit als 'hoogstens dit aantal kandidaten'. Dit voegt aanzienlijke betekenis toe bovenop het schema en maakt beide parameters duidelijk.

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?

De beschrijving start met een specifiek werkwoord ('Zoek') en resource ('een soort op wetenschappelijke of Nederlandse naam') en geeft het concrete resultaat ('GBIF-taxonsleutel(s)'). Dit maakt het doel direct duidelijk en onderscheidt het van de sibling-tools die andere functies vervullen (zoals waarnemingen of soorten_in_gebied).

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?

De beschrijving legt het zoekpad uit (eerst INBO, dan GBIF/BSL) en geeft context dat meerdere treffers ambigu kunnen zijn. Het noemt expliciet dat de taxon_key uit het resultaat in andere tools gebruikt moet worden, wat impliceert dat dit de eerste stap is. Het geeft echter geen expliciete uitsluitingen of alternatieve tools aan, dus een 4 is passend.

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