Search GBIF biodiversity occurrence records by species and/or country to find where organisms have been observed. Filter results by taxon key, ISO country code, and result limit.
Search GBIF biodiversity occurrence records by species and/or country.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10, max 50). | |
| country | No | ISO 2-letter country code. | |
| species_key | No | GBIF taxon key to filter by. |
Changes observed during successful MCP inspections.
v0.1.11Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing. It doesn't state that this is a read-only query, doesn't mention the 50-result cap or pagination, and doesn't characterize the return shape. For a zero-annotation search tool this is a substantial 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?
A single front-loaded sentence with no filler. The resource and its filter axes are stated immediately; nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search with no output schema and full parameter coverage this is minimally adequate, but it omits anything about result format, whether the two filters combine, or how it relates to sibling GBIF tools. No annotations mean those gaps are unfilled.
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, country, species_key) are already documented with formats and ranges in the schema. The description only restates the species/country filtering intent without adding syntax or format detail. Baseline 3 applies 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?
States a specific verb ('Search') and resource ('GBIF biodiversity occurrence records') and names the filter dimensions (species and/or country). This distinguishes it from siblings gbif_search_species and gbif_species_detail by operating on occurrence records rather than taxa. It lacks an explicit sibling callout but the resource noun is precise enough to differentiate.
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 guidance, no prerequisites, and no mention of the sibling species tools that an agent would need to choose between. 'By species and/or country' implies the filter combinations but doesn't say when this tool is the right pick over gbif_search_species.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.