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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive). The description goes beyond that by disclosing the return payload (title, authors, abstract, journal, citation info, GBIF usage details), which matters since no output schema exists.

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

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

Three tight sentences, front-loaded with purpose, then return contents, then usage. No filler or repetition.

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

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

For a single-param read tool with full annotations and a rich param description, the entry is essentially complete; it explains the return payload in the absence of an output schema. Only edge cases like invalid-DOI behavior are unaddressed, which is minor.

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

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

Schema coverage is 100% and the parameter description already details DOI format, examples, and where to source DOIs, so the schema does all the work. The description adds no param-level syntax beyond it, matching the baseline.

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

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

States a specific verb and resource ('Get complete metadata for a scientific publication by its DOI') and distinguishes itself from gbif_literature_search via the by-DOI lookup nature. Names the concrete fields returned, so an agent knows exactly what it fetches.

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?

'Use to get full details about a specific paper that used GBIF data' gives clear context for invocation and implicitly contrasts with search-style siblings. It stops short of explicitly naming the search tool or stating exclusions, but the usage condition is unambiguous.

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, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds no further behavioral context such as result ordering, pagination behavior, or result-size limits, so it neither exceeds nor contradicts 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 main purpose is front-loaded in the first sentence. The second sentence ('peer-reviewed publications, reports, and papers') is somewhat redundant with the first and could be tightened, but overall it is short and readable.

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 nine-parameter read-only search tool with fully documented schema and no output schema, the description covers the essentials of what the tool does and why it is useful. It omits any hint of return shape or default pagination behavior, but those are largely inferable from the 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 description coverage is 100%, so the schema already documents all nine parameters (q, year, limit, offset, topics, openAccess, peerReview, gbifDatasetKey, publishingOrganizationKey) in detail. The description adds no parameter-level meaning beyond that, which is the expected baseline when the schema does the heavy lifting.

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: 'Search scientific literature that cites GBIF data', elaborated with 'peer-reviewed publications, reports, and papers that used GBIF-mediated data'. This distinguishes it well from the occurrence/registry siblings, though it never explicitly contrasts with its closest sibling gbif_literature_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?

The third sentence gives usage motivation ('understanding data impact, finding research examples, tracking research trends'), which implies relevance context. However, there is no explicit when-to-use vs. when-not, no mention of gbif_literature_get as the single-record alternative, and no noted prerequisites.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description usefully adds that tiles are pre-rendered and fast to serve, but says nothing about authentication, rate limits, or caching.

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?

Four short sentences, front-loaded with what is produced, then characteristics. No filler, though the 'fast rendering' and 'quick visualization' points overlap slightly.

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

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

The tool returns a URL, which the description explicitly names as the output, so no output schema is needed. Combined with full schema coverage and rich annotations, an agent has enough to call it correctly; only sibling routing remains thin.

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

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

Schema description coverage is 100%, so every parameter (x/y/z, style, scale, year, country, taxonKey) is already documented in the schema. The description's mention of 'various color schemes' duplicates the style parameter docs without adding syntax or constraints. Baseline 3.

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

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

States a specific verb and resource: 'Generate URL for pre-rendered PNG density map tiles.' The PNG/raster nature clearly separates it in kind from the vector-tile sibling, even though that sibling is never named 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?

'Fast rendering, ideal for simple map displays. Use for quick visualization without client-side rendering overhead' implies the usage context but never states when to prefer this over gbif_maps_get_tile_url or gbif_maps_get_vector_tile_url, nor any 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 cover the safety profile (readOnlyHint, idempotentHint, non-destructive, openWorld), so the bar is lower. The description usefully discloses the return artifact (tile URL strings) and the projection (EPSG:3857 Web Mercator), but says nothing about behavior at out-of-range coordinates, rate limits, or why a generic tool exists alongside the raster/vector variants.

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

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

Two sentences, front-loaded with the action, no filler. The second sentence partially restates what the srs parameter already documents, which is minor redundancy but keeps the size appropriate.

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

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

With no output schema, the description does the right minimum of explaining that a tile URL is returned, which is adequate for a 12-parameter URL-builder. What is missing is the context an agent most needs: how this tool relates to its vector/raster siblings and the style-listing tool, leaving a real disambiguation hole.

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

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

Schema description coverage is 100%, so the schema already carries the semantics for all 12 parameters; baseline 3 applies. The description only gestures at 'customizable styling and filters' and otherwise adds nothing, and its blanket claim that tiles come back in EPSG:3857 sits slightly awkwardly against the srs parameter that permits EPSG:4326.

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

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

The description names a specific verb and resource: 'Generate a URL for occurrence map tiles,' scoped by styling and filters. That is clear on its own, but the sibling list contains gbif_maps_get_vector_tile_url and gbif_maps_get_raster_tile_url, and the description makes no attempt to distinguish this generic tool from those two near-identical siblings, which is the main ambiguity an agent faces here.

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 only guidance is a downstream-consumer list ('web mapping applications, GIS software, or direct visualization'), which describes what the URL is for rather than when to call this tool instead of the raster/vector tile siblings. With three overlapping tile-URL tools available, the absence of an explicit when-to-use and when-not-to-use rule is a real gap.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful context about what vector tiles enable (client-side styling, interactivity, dynamic rendering), but it does not add behavioral details beyond annotations, such as authentication requirements, rate limits, or what exactly the generated URL returns.

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 the core purpose and uses three sentences without excessive length. The second and third sentences are somewhat promotional but still useful for understanding intended use, so it is concise overall.

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

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

With no output schema, the description appropriately conveys that the tool generates a URL and describes its format and intended use. The annotations cover safety and idempotency, and the schema fully documents parameters, leaving only minor gaps such as how the returned URL should be used or whether any authentication is required.

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

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

Schema description coverage is 100%, so all nine parameters are already documented in the input schema, including tile coordinates, year filtering, style names, country codes, taxon keys, dataset keys, and basis of record. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb (Generate) and resource (URL for occurrence vector tiles) and specifies the format (Mapbox Vector Tile / MVT). It clearly distinguishes this from a raster tile tool by naming the vector format, though it does not explicitly contrast itself with the sibling gbif_maps_get_raster_tile_url or gbif_maps_get_tile_url.

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 implied usage context by naming ideal client libraries (Mapbox GL JS, Leaflet with vector tile plugins, OpenLayers), which helps an agent understand when this tool is appropriate. However, it does not provide explicit when-to-use versus when-not-to-use guidance, nor does it route the agent between this, the raster tile tool, or the generic tile URL 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/idempotentHint/openWorldHint and non-destructiveness, so the safety profile is covered. The description usefully adds the shape of the response (style names, descriptions, and types density/point/poly), which matters since no output schema exists.

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 tight sentences, front-loaded with the core action and then the return contents and routing hint. Every clause earns its place with no redundancy.

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

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

For a zero-parameter enumeration tool with no output schema, the description supplies everything needed: what it lists, what fields come back, and how it feeds into the tile-URL siblings. Nothing essential is missing.

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

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

Zero parameters, so the baseline is 4. The schema itself already states 'No input parameters required' at 100% coverage, and the description adds nothing misleading about inputs.

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

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

States a specific verb (List) and resource (map visualization styles for occurrence tiles), and immediately distinguishes itself from the tile-URL siblings as a discovery/enumeration tool. An agent can tell what it does without opening the schema.

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

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

Explicitly tells the agent when to use it ('discover visualization options before generating tile URLs') and names the specific sibling (gbif_maps_get_tile_url) as the follow-up. No when-not guidance is given, but the usage context 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 read-only, idempotent, non-destructive, open-world behavior; the description adds the 'fast' performance trait and that no full records are returned, but says nothing about return shape (single total vs. breakdown) or throttling 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 tight sentences, front-loaded with the fast/no-records distinction, and every phrase (statistics, dashboards, filter validation) adds real usage signal with no filler.

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

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

For a read-only count endpoint with fully documented params, the description is largely sufficient; the main missing piece is whether the result is a single number and how multiple filters combine (AND semantics).

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

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

Schema coverage is 100% with every one of the 19 filter params documented inline, so the schema carries the parameter burden. The description only characterizes the filters collectively, adding no syntax or semantics beyond the schema. Baseline 3 applies.

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

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

States a specific verb (counting) and resource (occurrences) with the key differentiator 'without retrieving full records,' which cleanly separates it from gbif_occurrence_search and the counts_by_* breakdown 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?

Gives clear usage contexts (statistics, dashboards, filter validation before full searches) and implicitly positions it ahead of full searches, but does not explicitly name the sibling to use when breakdowns by dimension are wanted.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds genuinely new behavioral context: the output shape (a breakdown of counts per type matching the filters) and a performance claim ("Very fast"), which helps an agent decide between this and slower search/count 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?

Four short sentences, correctly front-loaded with what the tool does and what it returns. The final sentence is slightly promotional ("Very fast") but still carries usable signal about latency; no significant filler.

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

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

With no output schema, the description usefully explains the return shape (per-type counts matching filters). All parameters are documented in the schema, and annotations cover the safety profile. It does not mention that all filters are optional (global aggregate) or how large result sets behave, which is a minor gap for a 0-required-param facet 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 100%, so all five filter parameters (year, country, taxonKey, datasetKey, hasCoordinate) are already documented with examples in the schema. The description only says results "match your filters" and adds no format or semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb (get counts), resource (occurrences), and facet (basis of record type), with concrete examples ("observations, specimens") that clarify what the grouping means. This implicitly distinguishes it from the plain gbif_occurrence_count and from other facet tools, but it never explicitly names a sibling or states how it differs from e.g. counts_by_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?

Gives a clear use context: "Essential for understanding dataset composition and data quality" and "use for dashboards and quick statistics." However, it offers no when-not guidance and does not route the agent to alternative facet tools when a different breakdown is actually wanted.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful trait, 'Fast statistics endpoint,' signaling lower cost/latency than a full search, plus a brief note on the return shape. It omits pagination/limits, but for a stats endpoint this is a modest gap.

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

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

Front-loaded with the verb and result, followed by scope, then rationale. Four short sentences, mostly earning their place. The 'Essential for...' clause leans slightly promotional but still conveys legitimate analysis use cases.

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?

Five optional filters, full schema coverage, and a complete safety annotation set; no output schema is present, so the description's one-line note on the return shape ('counts per country') is sufficient. Only pagination/size limits and the publishing-country distinction are unaddressed.

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

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

Schema description coverage is 100%, so all five filters are documented in the schema with examples (year range, taxonKey example, dataset, basisOfRecord, hasCoordinate). The description adds no parameter-level meaning, which is appropriate given the schema does the work — baseline 3.

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

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

States a specific verb and resource: 'Get occurrence counts broken down by country.' The geographic-distribution framing makes clear this is country-of-occurrence, not publishing country. However, it never names or contrasts with the very close sibling gbif_occurrence_counts_by_publishing_country, so disambiguation is left to the agent.

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

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

Gives use cases ('understanding species ranges, identifying data gaps by region, prioritizing conservation efforts') but these are motivations rather than when-to-use/when-not-to-use guidance. No alternatives are named, and the near-identical publishing-country sibling is not addressed.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructiveness, so safety is covered. The description adds the return shape ('dataset UUIDs with counts'), which is genuine value, but omits any result-set limits, ranking behavior, or pagination, which matter for a faceted count endpoint.

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

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

Three sentences, front-loaded with the core action and closed with the return type. The middle sentence is a list of use cases that earns its place for routing, though it is slightly longer than strictly necessary.

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

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

With no output schema, the description does supply the return shape and the tool has no required parameters, so an agent can call it correctly. It stops short of describing result volume, ordering, or truncation behavior, which is the remaining gap for a count/facet 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 100%, so all five parameters (year, country, taxonKey, basisOfRecord, hasCoordinate) are already documented with examples in the schema. The description adds no parameter syntax or filter-interaction detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource: 'Get occurrence counts broken down by contributing dataset.' The 'by dataset' dimension clearly distinguishes it from siblings like gbif_occurrence_counts_by_year, by_country, and by_basis_of_record without needing to read any schema.

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

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

Gives concrete usage contexts: 'data attribution, understanding data sources, finding primary datasets for a taxon/region, and acknowledging data providers.' However, it never names an alternative tool or states when NOT to use this one (e.g., when you only need a total count).

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered by structured data. The description adds no behavioral context beyond that: no note on response size, whether counts are exact or approximate, or any rate/caching behavior for a potentially large aggregation.

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

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

Three short sentences, front-loaded with the operation and dimension, followed by usage and then the critical disambiguation. No filler.

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

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

There is no output schema and no annotation of return shape, yet the description never states what the result looks like (an array/pairs of publishing country and count). For a counts endpoint this is largely inferable, but explicitly naming the return shape would close the only real 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 description coverage is 100%, so the baseline is 3. The description earns an increment because the 'different from occurrence country' sentence disambiguates the meaning of the country filter relative to the grouping dimension, which is the single most error-prone aspect of this 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?

Names a specific aggregation (occurrence counts) grouped by a precisely defined dimension (country of the publishing organization). The final sentence explicitly distinguishes it from occurrence country, which is the most likely confusion with the sibling gbif_occurrence_counts_by_country.

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

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

Gives three concrete use cases (provider distribution, collaboration opportunities, global participation) and an explicit contrast with the collection-country alternative. It stops short of stating when an agent should prefer this over gbif_occurrence_counts_by_publishing_org or gbif_occurrence_counts_by_dataset, so it is clear but not fully routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact — the return shape (organization UUIDs with occurrence counts), valuable since there is no output schema — but the remaining sentences are promotional rather than disclosing ordering, ranking, or pagination 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 core purpose and return shape are correctly front-loaded in the first and last sentences. The middle sentence is a four-item promotional list ('data attribution, understanding institutional contributions, acknowledging data providers, analyzing organizational participation') that mostly restates the same idea and does not earn 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?

With annotations covering safety, a 100%-covered schema, and the description supplying the return shape, an agent has enough to call the tool. The missing piece is sibling disambiguation within the large counts_by_* family, which leaves a real risk of selecting the wrong breakdown dimension.

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

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

Schema description coverage is 100%, so all five filters (year, country, taxonKey, basisOfRecord, hasCoordinate) are already documented, including a concrete taxonKey example. The description adds no parameter-level meaning beyond noting that results are 'for a query', so the baseline 3 is appropriate.

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

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

The first sentence states a specific verb and resource: occurrence counts broken down by publishing organization UUID. It is clear what the tool produces, but it never differentiates itself from the many sibling aggregation tools, notably gbif_occurrence_counts_by_publishing_country and gbif_occurrence_counts_by_dataset, which an agent could easily confuse with this one.

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 gives implied use contexts (data attribution, acknowledging data providers, analyzing organizational participation), which signals when the tool is relevant. However, it offers no explicit when-to-use vs. when-not, and never names an alternative sibling such as counts_by_dataset or counts_by_country when a different breakdown is wanted.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description nevertheless adds real behavior: results are sorted most-frequent-first and truncated to the top 100, plus a note that it is a fast statistics endpoint. That ordering/cap disclosure is exactly the kind of context annotations cannot carry.

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

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

Front-loaded with the core action and result shape, which is good, but the second and third sentences restate the same idea three ways ('taxonomic composition analysis', 'biodiversity patterns', 'identifying dominant species', 'taxonomic coverage') and 'Fast statistics for ecological analysis' is filler. It could lose a third of its length with no information loss.

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

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

With no output schema, the description carries the return-value burden and does so adequately (per-species counts, sorted, capped at 100). Filters are fully documented in the schema. What is missing is whether the endpoint applies implicit defaults or how a very large higher taxon is handled, but nothing critical to a correct call is absent.

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

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

Schema description coverage is 100% with 5 parameters, so the schema already documents year, country, datasetKey, hasCoordinate, and gives a taxonKey example. The description adds only the framing that counts are broken down by the species under the supplied taxon; no format, range, or default semantics beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb (get counts), resource (occurrences), and the breakdown dimension (species / speciesKey) that separates it from sibling count tools like gbif_occurrence_count and gbif_occurrence_counts_by_country. The scoping phrase 'within the filtered taxon' makes the aggregation level unambiguous.

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

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

Gives implied analytical contexts ('biodiversity patterns', 'dominant species') but never states when to choose this over gbif_occurrence_count or the other counts_by_* siblings, nor any prerequisite for taxonKey. Usage is inferable from the name and description but not directed.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description isn't burdened with that. It adds real context beyond annotations by disclosing the return shape ('year-by-year counts') and the performance trait 'Fast endpoint for dashboards'. It omits auth, pagination, and rate-limit 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?

Front-loaded with the core operation and reasonably sized. There is mild redundancy across 'temporal trend analysis', 'accumulated over time', and 'temporal coverage', but every sentence still contributes angle or return-shape 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?

With no output schema, the description correctly compensates by describing the return (year-by-year counts). Five optional filters are fully documented in-schema, and annotations carry the safety profile, so an agent has enough to invoke it correctly; only pagination/limits are unstated.

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

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

Schema description coverage is 100% with all five filters documented in-schema, so the structured data carries the semantics. The description mentions temporal filtering implicitly but adds no format, syntax, or defaulting detail beyond what the schema already supplies. Baseline 3 applies.

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

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

States a specific verb and resource ('Get occurrence counts broken down by year') and the distinguishing dimension (year) is front-loaded. This separates it from sibling tools like gbif_occurrence_counts_by_country or _by_dataset. It stops short of naming those siblings explicitly, so the agent must infer the contrast.

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

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

It lists use cases ('time series visualization', 'identifying data collection patterns', 'dashboards'), which implies when the tool is appropriate, but never states when to prefer it over the other counts_by_* siblings or any exclusions. Usage is implied rather than directed.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that the output is a predicate consumed by the download API, which is useful context, but says nothing about return format, whether the output must be passed through unchanged, or error behavior for invalid filters.

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 with no filler, and the core purpose is front-loaded. However, the second sentence largely restates the first ('build a download predicate from simple search parameters' vs 'converts occurrence search filters into the complex predicate format'), so there is mild redundancy.

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

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

For an 8-parameter helper with no output schema, the description should at least characterize the return value (the predicate shape/format) and how it feeds the download tool. It explains the role but leaves the agent uncertain about what it actually produces and how to use it next, which is a real gap for a tool with 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 description coverage is 100%, so the schema already documents all 8 parameters with examples (year ranges, ISO country codes, WKT winding order, taxonKey semantics). The description contributes no additional parameter meaning beyond what the schema provides, which is the expected baseline here.

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: it builds a download predicate from simple search parameters and converts occurrence search filters into the predicate format required by the download API. This is clearly distinguishable from listing/searching siblings, though it never names the specific download tool whose input it produces (e.g. gbif_occurrence_download_request).

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

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

Usage is implied by 'required by the download API', suggesting this runs before a download request, but the description never says when to use this versus other occurrence tools or explicitly names the alternative. No exclusions or prerequisites are given, so the agent must infer the workflow position.

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 this is a non-read-only, non-idempotent, open-world operation, but the description adds real value beyond them: it is asynchronous, it returns a download key, and it REQUIRES authentication via GBIF_USERNAME/GBIF_PASSWORD environment variables. Auth and async behavior are exactly the kind of operational context annotations cannot convey.

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

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

Three tight sentences with zero waste: purpose and scope first, return behavior second, authentication requirement last. The most decision-relevant constraint (large datasets / async) is 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?

For an async job-creating tool with no output schema, the description covers the essential gaps: async execution, the returned download key, and the auth prerequisite. It could go slightly further by stating what to do next (poll gbif_occurrence_download_status), but nothing critical is missing.

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

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

Schema description coverage is 100% and every parameter (format, creator, predicate, sendNotification, notificationAddresses) is fully documented in the schema, so the schema carries the parameter burden. The description only alludes to the predicate indirectly via the status/predicate-builder mention, adding no new parameter syntax or semantics.

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

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

States a specific verb and resource ('Request an asynchronous download') and scopes it precisely: 'for large occurrence datasets beyond pagination limits (100,000+ records)'. The pagination threshold implicitly distinguishes it from gbif_occurrence_search without the agent opening either schema.

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

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

Gives a clear condition for use (datasets beyond pagination limits, 100,000+ records) and hints at follow-up via 'checking status', implying gbif_occurrence_download_status. It does not explicitly name the alternative for smaller queries or state exclusions, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful non-annotation detail about the readiness lifecycle and return payload (status, link, record count, file size).

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

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

Two sentences, front-loaded with the action and followed by the return payload; no redundant or filler content.

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

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

With no output schema, the description usefully enumerates the return fields, filling that gap. It stops short of describing non-ready states (e.g., pending/failed) or retry guidance, which would complete the polling picture.

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

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

Only one parameter with 100% schema description coverage, which already states it is the key returned from gbif_occurrence_download_request. The description repeats rather than extends this, so baseline 3 is appropriate.

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

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

Names a specific verb ('Check the status and retrieve metadata') and resource ('occurrence download request'), and clearly contrasts with the sibling gbif_occurrence_download_request by focusing on status retrieval rather than initiating a download.

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 'when ready' phrasing implies this is polled after a download request, and the downloadKey param references gbif_occurrence_download_request, so the workflow context is inferable. However, there is no explicit statement of when to call this versus alternatives or how often to poll.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is low. Because there is no output schema, the enumeration of returned content (verbatim fields, interpretation history, media, quality issues) is genuinely useful behavioral context that tells the agent what data it will receive.

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 the verb and resource, with zero filler. Every clause earns its place by expanding what 'complete details' includes.

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 read tool with full annotation coverage, the description plus schema is nearly complete; the content enumeration compensates for the missing output schema. Only the routing against sibling lookup tools (search vs. verbatim vs. this) is left unaddressed.

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

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

Schema coverage is 100% and the single 'key' parameter is fully documented in the schema, including format, example and provenance ('found from search results'). The description adds no parameter-level detail beyond that, so baseline 3 applies.

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

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

States a specific verb (Get) and resource (a single occurrence record) and enumerates the payload categories: verbatim fields, interpretation history, media, data quality issues. This clearly separates it from gbif_occurrence_search/count (bulk) and gbif_occurrence_verbatim, though it never names those siblings 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 gives no guidance on when to call this versus gbif_occurrence_search or gbif_occurrence_verbatim, nor any prerequisite such as needing a key obtained from a prior search (that hint lives only in the schema). Usage is only inferable from the word 'single'.

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, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered without description help. The description adds that results are paginated and that facets can return aggregations, which is mild extra context, but it says nothing about rate limits, the 100k offset ceiling interaction, or result ordering — gaps the schema covers only partially.

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, both earning their place: the first front-loads what is searched and over what dimensions, the second immediately follows with the return shape. No filler, no restatement of the tool name.

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 42-parameter tool with no output schema, the description should carry more of the return-value burden than 'paginated results with optional facets' — it never indicates what fields come back per record or how facets are structured in the response. Annotations cover safety, but the read-result contract is left thin.

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 100% schema description coverage the baseline is 3, but the description earns a bump by giving a categorical map of the 42 parameters ('taxonomy, geography, time, data quality'), which orients an agent to the filter surface faster than scanning the schema. It still adds no per-parameter syntax or format detail beyond what the schema already documents.

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

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

States a specific verb and resource ('Search GBIF occurrence records') and elaborates the record types (species observations and specimens) plus the filter dimensions. It is clear what the tool does, but it never distinguishes itself from sibling tools that also read occurrence data (gbif_occurrence_count, the numerous gbif_occurrence_counts_by_* tools, or the download family), so an agent gets no routing help.

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

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

Usage is only implied: 'comprehensive filtering ... and more' suggests this is the general-purpose query entry point, but there is no explicit when-to-use guidance, no statement of when to prefer gbif_occurrence_count or the counts_by_* aggregators, and no prerequisites or exclusions. Adequate but leaves the alternative-selection decision to inference.

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

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

Annotations already establish the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint). The description adds genuinely useful context beyond that: the record is the publisher's raw submission and contains full Darwin Core fields with URIs. It does not cover auth or rate limits, but the annotation coverage lowers the bar.

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 tight sentences with zero filler, front-loading what the record is before the detail about containing original Darwin Core fields.

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

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

No output schema exists, so the description carries the return-value burden, and it does so reasonably by stating the record is the unprocessed publisher submission with all original Darwin Core fields and full URIs. It could say more about the exact payload shape, but it is sufficient for a single-key read-only 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?

With 100% schema description coverage and a single parameter, the schema already documents 'key' thoroughly (type, uniqueness, example, and purpose). The description adds nothing about the parameter, so the baseline 3 is appropriate.

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

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

The description states a specific verb (get) and resource (the original, unprocessed occurrence record as provided by the publisher) and adds a distinguishing scope qualifier: 'before GBIF interpretation.' This lets an agent separate it conceptually from the interpreted-record sibling, though it never names gbif_occurrence_get 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?

Usage is implied rather than stated: an agent can infer this is for retrieving publisher-original data instead of interpreted data, but there is no explicit when-to-use, when-not-to-use, or named alternative. The contrast with GBIF interpretation is the only routing signal.

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

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

Annotations already declare readOnly/idempotent/non-destructive and open-world, so the safety profile is covered. The description adds behavior annotations do not: it enumerates the content of the returned document (description, contacts, coverage, methods, project info) and states the format is structured XML, which matters given there is no 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?

Three sentences, front-loaded with the core action before the return description and use case. Each sentence carries information, though the final 'Essential for...' clause leans slightly promotional rather than operational.

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

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

With no output schema, the description correctly compensates by describing what the returned XML contains. Safety is covered by annotations and the single parameter is schema-documented, leaving little an agent needs that is missing; a note on document size or that XML parsing is required would close the remaining 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 description coverage is 100% and the single 'key' parameter is fully documented in the schema, including format, example, and return type. The description adds no new parameter meaning (no format hints, no alternative identifier types like DOI), so the baseline of 3 applies.

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

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

States a specific verb and resource: 'Get the EML (Ecological Metadata Language) metadata document for a dataset,' which is sharply distinct from the plain metadata returned by gbif_registry_get_dataset. It does not explicitly name that sibling or contrast the two, so an agent must infer the difference from the 'EML document' phrasing.

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

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

Gives concrete usage contexts ('proper dataset citation,' 'understanding data collection methods,' 'accessing complete metadata'), which tells the agent when this tool is the right one. It stops short of naming alternatives or exclusions, so there is no explicit when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds the shape of the output (counts by basis of record, country, year, quality indicators) but says nothing about auth needs, caching, latency, or stability of the metrics.

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

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

Three short sentences, front-loaded with the verb+resource and followed by the return shape and a use case. No filler, though the final sentence is somewhat redundant with the second.

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

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

With no output schema, the description usefully enumerates what is returned, and the lone parameter is fully specified in the schema. Safety is covered by annotations. Only the absence of guidance on when to prefer this over related dataset/occurrence tools keeps it from a 5.

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

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

Schema coverage is 100% and the single 'key' parameter is thoroughly documented in the schema itself (UUID format, example value, and where to obtain it). The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb and resource: 'Get occurrence statistics and quality metrics for a dataset.' An agent can tell it apart from gbif_registry_get_dataset (metadata) and gbif_species_metrics (taxon-level). It does not, however, explicitly name or contrast any sibling, so it stays at 4 rather than 5.

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

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

'Useful for understanding dataset composition and coverage' implies a use case but gives no when-to-use vs when-not, no prerequisites, and no alternative tools (e.g. get_dataset for metadata, occurrence counts tools for live queries). Usage is only implied.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds genuine value by enumerating the returned content categories, which partially compensates for the missing output schema. It stops short of describing completeness, size, or error behavior for an unknown key.

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

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

Two sentences, front-loaded with the action and resource, and the payload list is efficient. The final 'Essential for...' sentence is mild promotional filler that could be cut without losing selection signal.

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 one-parameter read with no output schema, the description does the necessary work by telling the agent what fields come back. Combined with full annotation coverage and a fully documented key, an agent has enough to call it correctly; only the absence of failure-mode detail keeps it from a 5.

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

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

Schema description coverage is 100% and the single 'key' parameter is fully documented in the schema, including its source ('Get from gbif_registry_search_collections'). The description adds nothing about the key beyond what the schema states, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get complete details for a specific scientific collection'), names the source registry (GRSciColl), and enumerates the payload (metadata, affiliation, holdings, contacts, preservation methods). This clearly separates it from the sibling gbif_registry_search_collections, which lists rather than retrieves a single record.

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 closing line ('Essential for understanding physical specimen repositories') gestures at when the tool is useful but names no alternative and no exclusion. It never says to obtain the key via gbif_registry_search_collections, nor how it relates to gbif_registry_get_institution. Usage is implied rather than directed.

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 this read-only, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds useful payload context by enumerating what comes back (title, contacts, endpoints, coverage, citation), which matters since there is no output schema, but it says nothing about auth needs, rate limits, or errors.

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, zero filler, with the operation and its key qualifier front-loaded and the return contents following. Nothing here would be cut without losing 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?

For a single-parameter read tool with annotations covering safety, the description is complete: it names what is fetched and enumerates the returned fields, compensating for the absent output schema. Only minor operational details (failure behavior on unknown UUIDs, rate limits) are missing.

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

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

Schema description coverage is 100%; the schema already fully documents 'key' (UUID format, example value, and how to obtain UUIDs from gbif_registry_search_datasets). The description only restates 'by its UUID' and therefore earns the baseline 3 rather than adding new parameter 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?

States a specific verb (Get) and resource (complete metadata for a GBIF dataset) qualified by the lookup key (by its UUID), so the agent can immediately tell this is a point-fetch rather than the listing tool gbif_registry_search_datasets. It does not explicitly distinguish itself from the other per-dataset siblings (dataset_metrics, dataset_document), which is the only thing keeping it from a 5.

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

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

Usage is implied rather than stated: fetching 'by its UUID' signals it is only appropriate when the UUID is already known, and the schema points to gbif_registry_search_datasets for discovery. There is no explicit when-not or named alternative (metrics/document) to route the agent among the per-dataset 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 declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds real value on top by disclosing what the response contains (technical endpoint information, hosting organization, datasets served), which matters because there is no 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?

Two tight sentences, zero filler, front-loaded with the action and resource before the return-value 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 read with full schema coverage and rich annotations, the description supplies enough; the return-content summary compensates for the absent output schema. It is only slightly thin on how the result differs from a search hit.

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

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

Schema description coverage is 100% and the schema already documents the key as a UUID with its source tool, so the baseline is 3. The description adds nothing about the parameter itself.

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

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

States a specific verb ('Get') and resource ('a specific IPT or data server installation') and even names the returned content. The word 'specific' implicitly separates it from gbif_registry_search_installations, but no sibling is named explicitly, so it falls just short of a 5.

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

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

Usage is only implied: the word 'specific' suggests this is the detail-fetch to follow a search, and the schema's key description points to gbif_registry_search_installations. The description itself gives no explicit when-to-use or when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description goes beyond them by naming the return payload (metadata, collections, contacts, addresses, identifiers), which matters since there is no output schema. It does not mention auth, rate limits, or error behavior for unknown keys.

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, front-loaded with the action and resource, followed by the payload and a use case. No filler or repetition.

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

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

For a single-parameter read tool with no output schema, the description covers action, returns, and intent adequately. Minor gaps remain around absent-key behavior and the relationship to the search tool, but nothing essential to invoking it is missing.

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

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

Schema coverage is 100% and the single 'key' parameter is fully documented, including format (uuid), an example, and the source sibling (gbif_registry_search_institutions). The description adds nothing beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get complete details for a specific scientific institution from GRSciColl') and enumerates the returned content. The singular 'specific institution' implicitly contrasts with the sibling search tool, but no sibling is named explicitly in the description itself.

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?

'Use to understand institution profiles and their collection holdings' gives a purpose-driven context, but there is no explicit when-to-use versus gbif_registry_search_institutions, nor any exclusion or prerequisite (e.g. needing a key from search first). Usage 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds that the response includes constituent datasets, contacts, and description text, which is useful given there is no output schema, but it says nothing about invalid-key behavior or pagination of the constituent datasets.

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

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

Three short sentences, front-loaded with the action and resource, followed by return contents and intended use. No filler, though the final 'Use to...' sentence is the weakest and could be more directive.

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 read tool with no output schema, the description compensates reasonably by naming the return payload (metadata, constituent datasets, contacts, description). Errors and response shape details are absent but minor for a simple lookup.

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

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

Schema coverage is 100% and the key parameter is fully described (UUID format, examples, and where to obtain it). The description adds nothing beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('Get complete details for a specific dataset network') and enumerates what it returns (metadata, datasets, contacts, description). It reads as the by-id counterpart to gbif_registry_search_networks, but it never names that sibling explicitly, so differentiation relies on the sibling's own name.

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?

'Use to understand collaborative data initiatives and their scope' gives a purpose but not a when-to-use rule or an alternative. The routing hint (get the key from gbif_registry_search_networks) lives in the schema, not the description, so usage is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior. The description adds the shape of returned fields, which is useful, but doesn't disclose error behavior (e.g., invalid UUID, not found) or anything beyond the annotation profile.

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

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

Three tight sentences: purpose, return contents, usage context. Front-loaded and no filler.

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

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

For a single required-param read tool with full schema coverage and comprehensive annotations, the description covers purpose, return shape, and usage context adequately. No output schema exists, but the description enumerates the main returned fields, which is sufficient; arguably could mention key sourcing but the schema already does.

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

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

Schema coverage is 100% and the schema description already explains the key is a node UUID obtained from gbif_registry_list_nodes. The description adds no parameter-level detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (Get) and resource (GBIF participant node), and enumerates what the response contains (metadata, contacts, participation type, country, endorsement). Clearly distinguishable from siblings like gbif_registry_list_nodes or gbif_registry_get_organization.

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

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

Gives a clear purpose context ('Use to understand national GBIF participation, governance structure, and institutional membership') implying when to reach for it. Does not explicitly name an alternative tool or exclusion criteria, so not a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description still adds value by disclosing the payload contents (contacts, addresses, datasets published, endorsement status, institutional information), which matters because no output schema exists.

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, zero filler: purpose first, returned fields second. Every clause earns its place and the core action is 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?

A simple idempotent read with full schema coverage and annotations carrying the safety profile. The description compensates for the missing output schema by listing key returned fields; only richer detail on the returned structure would push it higher.

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 a single parameter at 100% schema coverage, the schema already documents 'key' fully, including its UUID format, an example, and the sibling tool to obtain it. The description adds no further parameter meaning, so the baseline 3 applies.

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

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

Specific verb 'Get' plus a precise resource ('a specific data-publishing organization') and an enumeration of what comes back. The resource noun cleanly separates it from sibling lookups like get_network, get_installation, get_collection and get_institution without the agent needing to open any schema.

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

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

Usage is only implied: it is a fetch-by-key operation for one known organization. There is no statement of when to prefer it over gbif_registry_search_organizations or gbif_registry_organization_datasets, and no prerequisites or exclusions are given.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive, so safety profile is covered. The description adds conceptual context about what nodes represent but discloses nothing about pagination behavior, result size, or return shape 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?

Three compact sentences, front-loaded with the core action, followed by definitional context. No filler or repetition.

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

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

For a simple read-only list tool with full schema coverage and annotations, the description supplies adequate conceptual grounding. Only a note on when to prefer sibling search tools is missing, a minor 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 description coverage is 100%, so all three parameters (limit, offset, country) are fully documented in the schema. The description adds no parameter detail beyond the schema baseline.

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

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

Specific verb 'List' plus resource 'GBIF participant nodes' with a clarifying gloss that nodes are national/organizational participants. Clearly distinguished from siblings like gbif_registry_get_node (single node fetch) and search_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?

States it is 'essential for understanding GBIF network structure...' which implies context of use, but never says when to use this versus search_organizations, search_networks, or get_node, and gives no 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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds domain context about what a network represents but says nothing about pagination behavior, result size, or rate limits beyond what the schema already documents.

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

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

Three short sentences, front-loaded with the core action before the explanatory context. No filler, though the second sentence ('Shows which datasets are part of a collaborative network') largely restates the first.

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 paginated read-only list with 100% schema coverage and annotations carrying the safety profile, the definition covers what an agent needs. It omits any note on the returned list shape, which is a minor gap given there is 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 description coverage is 100%, including how to obtain networkKey and the limit/offset semantics, so the baseline is 3. The description adds no parameter-level meaning beyond the schema.

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

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

Specific verb ('List') plus a precisely scoped resource ('constituent datasets within a specific network'). The 'within a network' qualifier implicitly separates it from siblings like gbif_registry_organization_datasets and gbif_registry_search_datasets, but no sibling is named, so it falls short of a 5.

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

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

The closing sentence hints at usage ('useful for exploring thematic data collections like eBird...'), which is implied guidance rather than an explicit when-to-use rule. It never states when NOT to use this tool or which alternative to pick (e.g., search_datasets for non-network scoping).

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds only a mild scope claim ('complete catalog') but says nothing about pagination behavior, result volume, or what happens with very large publishers, so it does not meaningfully extend 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?

Front-loaded with the core action, which is good, but the second and third sentences restate the same idea twice ('complete catalog of datasets contributed by an institution' / 'useful for understanding an organization's data contributions and portfolio'), so two of three sentences are largely redundant padding.

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?

There is no output schema, yet the description does not indicate what a returned dataset entry contains, and parameter behavior is left entirely to the schema. For a simple read/list tool with full schema coverage this is adequate but leaves the agent with no picture of the response shape.

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

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

Schema description coverage is 100%: the enum values for type, the range/default for limit and offset, and the UUID format plus source tools for organizationKey are all documented inline. The description adds no additional parameter meaning, so the baseline 3 applies.

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

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

States a specific verb (List) and resource (datasets) with a clear scope qualifier (published by a specific organization), so an agent can distinguish it from the generic gbif_registry_search_datasets. However, it never names or routes against siblings like gbif_registry_search_datasets, gbif_registry_get_organization, or gbif_registry_network_datasets, which is the classic 'clear but no sibling differentiation' case.

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?

'Useful for understanding an organization's data contributions and portfolio' gestures at a use case but gives no when-to-use condition, no exclusions, and no alternative tools (e.g., use search_datasets instead when organization is unknown). Nothing tells an agent when this tool is the wrong choice.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorld, so the agent knows this is a safe, repeatable read against an open registry. The description adds no behavioral context beyond that - no pagination semantics, result ordering, or registry coverage limits - so it neither contradicts nor enriches the annotation profile.

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

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

Three short sentences, front-loaded with the resource name and scope, with no filler. The last sentence is somewhat thin ("and their metadata") but still earns its place as a usage cue.

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

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

With no output schema, the description shoulders the return-value burden; "discover physical specimen holdings and their metadata" only loosely signals the return shape, and pagination via limit/offset is left to the schema. For a 7-param, optional-only search tool with full annotation coverage, this is nearly complete but not fully self-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?

Schema description coverage is 100%, so all seven parameters (q, city, code, limit, offset, country, institution) already carry examples and constraints in the schema. The description adds no additional filter semantics, which makes the baseline 3 appropriate.

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

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

States a specific verb (Search) and resource (GRSciColl natural history collections) and enumerates the collection types covered (museum, herbarium, tissue). It is clearly distinct from siblings like gbif_registry_search_datasets or gbif_registry_search_occurrences, but it never names the nearest-neighbor alternative (gbif_registry_search_institutions), leaving that differentiation to inference.

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?

"Use to discover physical specimen holdings and their metadata" gives a usage context, so it is more than nothing. However, it offers no when-not guidance, no mention of when to prefer search_institutions or get_collection, and no prerequisites (e.g., obtain institution UUIDs first, which the schema mentions but the description does not reinforce).

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the safety profile is covered. The description adds one useful behavioral detail — that only *published* datasets are returned — but says nothing about result caps, pagination limits, or response shape. A 3 is appropriate against a strong annotation set.

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

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

Three tight sentences with the core action front-loaded and zero filler. The final sentence is somewhat soft ('Essential for...') but not wasteful enough to drop below 4.

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?

Nine parameters are fully documented in the schema, but with no output schema the description carries some burden for explaining returns and it stays silent on result structure, total counts, and pagination behavior beyond what the limit/offset schema params imply. Adequate but with a visible 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 description coverage is 100%, so the schema already documents all nine parameters in detail; baseline 3 applies. The description's filter list adds no syntax or format detail beyond the schema, and its mention of 'taxonomic scope' corresponds to no actual parameter, which is mildly imprecise.

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

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

States a specific verb and resource: 'Search for datasets in the GBIF registry,' and names the filtering dimensions. It is clearly distinguishable from gbif_registry_get_dataset (single fetch) and gbif_registry_dataset_metrics, though it never names those siblings 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?

'Essential for discovering data sources' implies a discovery use case but gives no explicit when-to-use/when-not guidance, no mention of the alternative get_dataset for full metadata, and no prerequisites. Usage is inferable but not 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds conceptual context about what IPTs are but says nothing about result volume, pagination behavior, or return shape, so it adds only modest value beyond structured fields.

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

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

Three short sentences with the core verb-resource pairing front-loaded and zero filler; every sentence (including the IPT definition) earns its place by aiding selection.

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

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

For a read-only search with full schema coverage and no output schema, the definition covers purpose and domain context adequately. It stops short of describing result structure or paging semantics, but nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100%, with q, type, limit, and offset each fully documented in the schema. The description adds no parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ("Search") and resource ("IPT installations") and explicitly disambiguates from siblings searching organizations, networks, datasets, and collections. It even defines what an IPT is, so an agent can select it without opening the schema.

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

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

"Use to find technical infrastructure and data hosting platforms" gives a use context, but no when-not guidance and no reference to the sibling gbif_registry_get_installation (lookup by key) that would let an agent distinguish search from retrieval.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no mention of pagination behavior (limit/offset), result volume, or what a result record contains — so it earns no extra credit.

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 with the purpose front-loaded and no filler; the second sentence usefully enumerates the institution types returned. It is well-sized, though the second sentence does not add routing or behavioral 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?

Annotations carry the safety profile and the schema fully documents all parameters, so the core need is met. Still, with no output schema, the description could reasonably say what a result contains (name, code, city, country) or note pagination via limit/offset; that gap keeps it merely adequate.

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

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

Schema description coverage is 100%, with each of the six filters (q, city, code, limit, offset, country) documented with examples and constraints. The description contributes no additional parameter semantics, so the baseline of 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?

Names a specific verb (Search) and resource (scientific institutions in GRSciColl) and enumerates the kinds of entities returned (museums, herbaria, universities). However, it does not distinguish 'institutions' from the closely related sibling tools gbif_registry_search_organizations and gbif_registry_search_collections, so an agent must infer which registry entity type it needs.

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?

There is no statement of when to use this tool versus gbif_registry_search_organizations, gbif_registry_search_collections, gbif_registry_get_institution, or gbif_registry_list_nodes. The description describes the content available but gives no routing guidance or prerequisites, leaving selection entirely to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety and repeatability are fully covered structurally. The description contributes domain context (what networks are) but says nothing extra about result format or pagination semantics beyond what the schema's limit/offset descriptions give. Adequate, not rich.

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 front-loaded sentences: purpose first, domain explanation second. No wasted clauses. The parenthetical example list is slightly long but earns its place by disambiguating the term 'network'.

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, read-only, open-world search tool with 100% schema coverage and full annotations, the definition supplies what the structured fields cannot: the meaning of 'network'. No output schema exists, but for a list endpoint the return shape is predictable. Minor gap: no note on pagination behavior when results exceed limit.

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

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

Schema description coverage is 100%, so all four parameters (q, limit, offset, identifier) are documented in the schema with examples and ranges. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource: 'Search for dataset networks in GBIF', and defines what a network is with concrete examples (eBird, iNaturalist, OBIS). It does not explicitly distinguish itself from siblings like gbif_registry_get_network or gbif_registry_search_organizations, but the resource noun 'networks' is clear enough to route by.

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?

'Use to discover thematic data collections and partnerships' implies the browse/discovery use case but names no alternatives and gives no when-not condition. An agent can infer it should use get_network for a single known network, but the description never says so.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), so the bar is lowered. The description adds no behavioral context beyond this—nothing about pagination interaction between limit/offset, rate limits, or the shape/volume of results—so it earns little credit.

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

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

Three front-loaded sentences: purpose, concrete examples, then use case. All sentences contribute; no filler or repetition. Slightly more verbose than strictly necessary but well structured.

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

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

For a 5-param read-only search with full schema coverage and no output schema, the description covers purpose, examples, and intended use. Annotations carry the safety profile. It is essentially complete, though return-value expectations are left implicit.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters (q, limit, offset, country, isEndorsed) with examples and ranges. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

States a specific verb (search) and resource (data-publishing organizations in the GBIF network), and names concrete examples (museums, herbaria, research institutions). It does not explicitly distinguish itself from sibling search tools like gbif_registry_search_networks or gbif_registry_get_organization, so it stops short of a 5.

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

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

"Use to discover data providers and understand institutional participation" gives an implied use case, but there is no when-not guidance and no routing to alternatives such as get_organization (for a single org) or organization_datasets. Adequate but with clear gaps.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that only direct children are returned, not the full descendant subtree — but says nothing about result format or ordering.

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, front-loaded with the core action and scope qualifier; the parenthetical example earns its place by making the hierarchy direction unambiguous. No filler.

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

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

For a simple read-only lookup with full schema coverage, the essentials are present, and pagination is handled by the schema's limit/offset docs. However, with no output schema, the description does not indicate what a returned child entry contains (key, name, rank), leaving a modest 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 100% and the schema already documents key, limit, and offset thoroughly, including an example parent key. The description's parenthetical examples echo that without adding syntax or semantics beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource: 'Get direct taxonomic children of a taxon', with concrete examples (species under a genus). The word 'direct' contrasts implicitly with the sibling gbif_species_parents and with recursive descendants, but no sibling is named 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?

'Useful for exploring taxonomy hierarchically' implies a use case but gives no explicit when-to-use/when-not guidance against alternatives such as gbif_species_parents, gbif_species_related, or gbif_species_get. The agent must infer which taxonomy-navigation tool fits.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds useful context beyond that: descriptions come 'from various sources' (implying variable provenance and possibly multiple records per species) and the content is narrative, not structured.

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 tight sentences, front-loaded with the action and resource, followed by the content scope. No redundant or padding language.

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

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

For a read-only lookup with full schema coverage and no output schema, the description tells the agent what kind of content comes back and that sources vary. It is nearly complete, missing only an explicit pointer to sibling species 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 100%; key, limit and offset are fully documented in the schema, including a Panthera leo example and pagination semantics. The description adds no parameter-level information, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get textual descriptions for a species') and enumerates the content types (morphology, habitat, behavior). It is clearly distinguishable from functional siblings like gbif_species_media or gbif_species_distributions, though it does not explicitly name them.

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

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

Usage is implied: fetch narrative text for a species. There is no explicit when-to-use, no exclusions, and no mention of the related species siblings (media, vernacular_names, distributions) that an agent might confuse it with.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds useful content context by naming the record fields (occurrence status, establishment means, locality details), but it does not mention pagination behavior, rate limits, or authentication requirements. This is adequate but not rich.

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, zero waste, and the core purpose is front-loaded. The second sentence efficiently lists the record contents without padding.

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 read-only list tool with a fully described schema and safety annotations, the description is nearly complete. It conveys the return-content categories, though it stops short of noting that results are paginated or describing the record shape, which would help since no output schema exists.

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

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

Schema description coverage is 100%, so the schema already fully documents key, limit, and offset. The description adds no parameter-level meaning, syntax, or format details beyond what the schema provides. A baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Get known geographic distribution records for a species.' It clarifies the kind of data returned (occurrence status, establishment means, locality details), which separates it from generic species lookup tools. It does not explicitly name sibling alternatives like gbif_species_get or gbif_occurrence_search, so it falls short of a 5.

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

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

There is no when-to-use guidance, no exclusions, and no mention of alternative tools. An agent must infer that this is for distribution data specifically and cannot tell from the description alone how it differs in use case from gbif_species_get, gbif_maps_get_tile_url, or gbif_occurrence_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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safe-read profile is fully covered and the bar is low. The description adds no behavioral context beyond the annotations (no note on what the record contains, caching, or missing-key behavior), so it is merely adequate rather than enriching.

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 filler; the verb, resource, and input are all in one clause.

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 read tool with comprehensive annotations and no output schema, the definition is nearly sufficient. The remaining gap is that it never characterizes what 'detailed information' comprises, which matters given how many sibling tools carve up species data.

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

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

Schema coverage is 100%: the 'key' property is documented in rich detail (usageKey, backbone taxonomy, worked example 5219404 for Panthera leo). The description adds nothing beyond the schema, so baseline 3 applies.

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

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

States a specific verb ('Get') and resource ('detailed information about a specific species') keyed by GBIF key. However, 'detailed information' is vague against a large sibling family (gbif_species_descriptions, gbif_species_media, gbif_species_metrics, gbif_species_synonyms, gbif_species_vernacular_names) that each return a specific slice; the description does not clarify that this returns the core species record as opposed to those specialized subsets.

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 when-to-use, when-not-to-use, or alternative is mentioned. It gives the input form ('by its GBIF key') but nothing that helps an agent choose between this and the many other species 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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral notion that matching is fuzzy, but says nothing about result confidence, no-match behavior, or what happens with ambiguous names. With annotations doing the heavy lifting, a 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?

A single tight sentence with the core action front-loaded and no filler. It is efficient, though it is arguably too sparse for a tool whose output shape and disambiguation behavior matter.

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 read-only, fully-schema-documented tool this is nearly adequate, but with no output schema the agent has no idea what a 'match' returns (accepted name, taxon key, confidence, alternatives). That gap matters for deciding whether to call this versus sibling species 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 coverage is 100%: both 'name' and 'strict' are fully documented in the input schema, including the fuzzy/strict distinction and an example. The description adds no syntax or format detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific verb (fuzzy match) and resource (species name) plus the target authority (GBIF backbone taxonomy), so the agent knows exactly what the tool does. However, it does not distinguish itself from near-neighbors like gbif_species_parse_names, gbif_species_suggest, or gbif_species_search, leaving the agent to guess which matching tool fits a given case.

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 offers no when-to-use guidance, prerequisites, or named alternatives, despite several similar species tools in the sibling list. The only usage-like hint (fuzzy vs strict) lives in the schema, not the description, so the agent gets no routing help here.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description reinforces openWorld by noting media come 'from various sources' and that it returns URLs plus metadata, but adds no auth, rate-limit, or pagination-behavior detail 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?

Two short sentences, front-loaded with the core action and content types, with the return-shape note second. No filler or repetition.

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

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

With no output schema, the description usefully states that it returns URLs and metadata, and all three parameters are fully specified in the schema. Missing only minor context such as typical volume of results or attribution/licensing caveats hinted at in the 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 description coverage is 100%; the key, limit, and offset parameters are all thoroughly documented in the schema, including an example species key and pagination semantics. The description adds no parameter-level meaning, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Get associated multimedia records for a species') and enumerates the content types (images, sounds, videos), so the agent can tell it apart from gbif_species_get or gbif_species_descriptions conceptually. It does not, however, explicitly name or contrast with any sibling tool.

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

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

Usage is implied by the purpose: call it when you want media for a known species key. There is no explicit when-to-use, when-not-to-use, or alternative routing (e.g., when to prefer occurrence media or how it relates to gbif_species_descriptions).

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by disclosing exactly which aggregates come back and that the endpoint is fast/lightweight, though it says nothing about rate limits or pagination 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?

Three tight sentences, front-loaded with the core action and output list, followed by usage context. The 'perfect for...' phrasing is slightly promotional but still earns its place as routing 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?

For a single-parameter, read-only aggregate tool with no output schema, the definition is largely complete: it explains what is returned and when to use it, and annotations cover safety. Only minor gaps remain (no mention of what happens with an invalid key or any caching/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 100% and the single 'key' parameter is already fully documented in the schema, including an example. The description adds nothing about the parameter itself, so the baseline 3 applies.

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

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

States a specific verb and resource (get occurrence statistics for a species) and enumerates the exact metrics returned, which helps distinguish it from the many search/count siblings. It contrasts with 'full searches' but never names the specific alternative tools (e.g. gbif_occurrence_count or gbif_occurrence_search), so differentiation is implied rather than 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?

Provides clear usage context ('perfect for species profile pages, dashboards, and quick data availability checks') and implicitly routes away from heavyweight searches. However it never states when NOT to use it or names a concrete alternative endpoint, so it stops short of explicit when/when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is fully covered. The description adds that the response is the full hierarchy of parent taxa, which is useful given there is no output schema, but says nothing about behavior for root taxa or invalid keys.

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

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

Three short sentences, front-loaded with the core action. Minor redundancy between 'complete taxonomic classification path' and 'full hierarchy including all parent taxa,' but no filler.

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

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

For a single-parameter read-only tool with full annotation coverage, a 100%-documented schema, and no output schema, the description supplies the response shape (kingdom-to-taxon lineage). Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100% and the single 'key' parameter is documented in the schema with an example (5219404 Panthera leo) showing the exact return lineage. The description adds no meaning beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb and resource: 'Get the complete taxonomic classification path from kingdom down to the specified taxon.' The upward direction of traversal is clear, which implicitly separates it from descendant-oriented siblings, but no sibling is named explicitly (e.g., gbif_species_children, gbif_species_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?

'Useful for breadcrumb navigation and understanding taxonomic position' gives an implied usage context, but there is no explicit when-to-use guidance or when-to-prefer-an-alternative statement among the many species_* siblings. Adequate but leaves routing to inference.

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

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

Annotations already declare readOnly, idempotent, open-world, and non-destructive, so the safety profile is covered. The description's only behavioral addition is the 1000-name batch cap, which is duplicated in the schema, and it says nothing about how unparseable names are reported or what the quality indicators mean. Modest 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?

Three tightly packed sentences: what it does, what it extracts, why it matters, and the size limit. Front-loaded and free of redundancy, though 'Essential for...' is mildly promotional rather than informational.

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 read-only parser with no output schema, the description supplies the batch limit, the extracted components, and the use context; the schema's parameter text also enumerates returned fields. Missing only failure/quality behavior for unparseable names, which is a minor 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?

There is a single parameter with 100% schema description coverage, including format examples and a list of returned components, so the schema carries the load. The description only restates the batch limit and extracted fields rather than adding new semantics. Baseline 3 applies.

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

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

States a specific verb+resource ('Parse and standardize scientific names') and adds scope ('in batch') plus output fields (genus, species, authorship, rank). However, it never distinguishes itself from close siblings like gbif_species_match, gbif_species_suggest, or gbif_species_search, which an agent could plausibly confuse with name parsing.

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

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

Gives concrete contexts for use: data cleaning, quality checking, and standardizing names from spreadsheets or databases. It stops short of naming alternatives or stating when NOT to use it (e.g., single-name lookups should go to gbif_species_match), so it is clear context without 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, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds useful context about the nature of the result ('species at the same taxonomic level with shared higher classification'), but says nothing about result volume, paging behavior, or edge cases like a leaf taxon with no siblings.

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

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

Three sentences, front-loaded with the core definition of what 'related' returns before the softer use-case list. No filler, though the second sentence is a somewhat generic benefit list that could be trimmed.

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

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

With no output schema, the description carries the burden of describing returns and does so at a high level ('species at the same taxonomic level with shared higher classification'). Combined with rich annotations and full schema coverage, an agent has enough to call it correctly, though a note on what fields come back would complete it.

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

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

Schema description coverage is 100%: key, limit, and offset are all documented in the schema, including an illustrative example for key and range/default details for limit/offset. The description adds no parameter-level meaning beyond that, so the baseline of 3 is appropriate.

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

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

States a specific verb+resource ('Get related species') and defines 'related' explicitly as siblings (same parent taxon), variants, and associated taxa, which disambiguates it from vaguer notions of relatedness. However, it never names the sibling tools it overlaps with (gbif_species_children, gbif_species_parents, gbif_species_synonyms), so the agent must infer the boundary itself.

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?

Offers use cases ('taxonomic exploration', 'see also' functionality, 'discovering similar species'), which implies when it is appropriate, but gives no explicit when-to-use vs alternatives and no exclusions against the many sibling taxa tools. 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds essentially nothing beyond that – no note on pagination behavior, result volume, or performance – so it sits at the minimum viable level given rich 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 the core action, with no repetition. The trailing 'and more' is mild filler that could have been replaced with a routing hint, keeping it short of 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?

For a 17-parameter, zero-required search tool with no output schema, the description is thin: it doesn't describe the result shape, pagination expectations, or how the large optional filter set is meant to be combined. Annotations and schema carry most of the load, but an agent still lacks selection context versus sibling species 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 100% and every one of the 17 parameters carries its own description with enum values and examples. The phrase 'rank, status, habitat, threat level, and more' just echoes a subset of the schema, adding no new meaning, so the baseline 3 applies.

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

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

States a specific verb (Search) and resource (species in the GBIF taxonomic backbone), which is clear on its own. However, it does nothing to distinguish itself from close siblings like gbif_species_suggest or gbif_species_match, which also take name-like queries, so an agent must infer the boundary.

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 lists filter categories but gives no when-to-use guidance and no exclusions relative to the many sibling species tools. It never says when to prefer this over gbif_species_suggest (autocomplete) or gbif_species_match (name resolution), which is the main routing decision an agent faces.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description's only added behavioral signal is the autocomplete framing (partial-match, suggestion-style output); it says nothing about ranking, whether vernacular names are included, or result ordering.

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 eight-word sentence with the verb and purpose front-loaded; nothing is wasted or buried.

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

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

For a simple two-parameter lookup with full schema coverage and annotations carrying the safety profile, the definition is minimally viable. It is still thin on the one thing that matters here: how suggestions differ from gbif_species_search results, which is not covered by any structured field.

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

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

Schema description coverage is 100% and the q/limit parameters are fully documented in the schema (min length, range, defaults, example). The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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

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

The description states a specific verb and resource ("Get species name suggestions") and the "autocomplete" framing signals partial/prefix lookup rather than full search. However, it never names or contrasts with close siblings like gbif_species_search, gbif_species_match, or gbif_species_parse_names, so an agent must infer the boundary.

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

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

Usage is implied by "for autocomplete functionality," which tells the agent this is a typeahead-style lookup rather than a full search. There is no explicit when-to-use/when-not guidance and no alternative tool named, leaving the routing decision against gbif_species_search to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds no behavioral context beyond that, such as whether results are paginated or how synonyms are ordered. With annotations carrying the safety burden, a 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?

Two short, front-loaded sentences with no redundancy. The second sentence is slightly soft ('useful for...') but does earn its place as the only usage signal present.

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