gbif-biodiversity-mcp-server
Server Details
Search GBIF species taxonomy, occurrence records, datasets, and publishers.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/gbif-biodiversity-mcp-server
- GitHub Stars
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 12 of 12 tools scored.
Each tool has a clearly distinct purpose: counting, getting, searching, matching, and faceting. There is no overlap between tools; even similar functions like match_species and search_species are differentiated by exact matching vs. browsing.
Most tools follow the pattern 'gbif_<verb>_<noun>' with verbs like get, search, count, match. The exception is gbif_occurrence_facets, which uses a noun phrase without a verb, making it slightly inconsistent but still readable.
12 tools is well within the ideal 3-15 range. The number feels appropriate for the domain, covering core operations without being overwhelming or sparse.
The tool set covers essential workflows: species resolution, occurrence search/retrieval/counting/faceting, dataset and publisher search, and taxonomic hierarchy. Minor gaps exist (e.g., no download tool), but the surface is largely complete for typical biodiversity data access.
Available Tools
12 toolsgbif_count_occurrencesCount OccurrencesARead-onlyIdempotentInspect
Count occurrences matching a taxon + location filter without fetching records. Use for quick totals ("how many Aves records in Sweden?") or before deciding whether to paginate a full search. Accepts taxonKey, country, isGeoreferenced, datasetKey, and year.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year or year range (e.g., "2024" or "2020,2024"). | |
| country | No | ISO 3166-1 alpha-2 country code (e.g., "GB", "US"). | |
| taxonKey | No | GBIF backbone taxon key from gbif_match_species. | |
| datasetKey | No | Filter to a specific dataset UUID. | |
| isGeoreferenced | No | When true, count only georeferenced records. When false, count only non-georeferenced records. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Total occurrences matching the supplied filters. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. Description adds the key behavioral detail that it counts without fetching records, which is essential for correct invocation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero wasted words. Front-loaded with the action ('Count occurrences') and purpose, followed by usage context and parameter list. Ideal conciseness for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description does not need to detail return values. It covers purpose, usage, and parameters sufficiently for a simple count operation. Complete for an agent to decide and invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 5 parameters with descriptions, achieving 100% coverage. The description lists parameter names but adds no additional meaning beyond what the schema provides. 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?
Description explicitly states counting occurrences for a taxon+location filter, provides concrete use cases ('how many Aves records in Sweden?'), and lists accepted parameters. Clearly distinguishes from sibling tools like gbif_search_occurrences (fetching records) and gbif_occurrence_facets (aggregations).
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 when to use: quick totals or before deciding to paginate a full search. Implies alternative is gbif_search_occurrences for actual records, though not explicitly named. Context from sibling names supports this differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gbif_get_datasetGet DatasetARead-onlyIdempotentInspect
Fetch full dataset metadata by UUID key — title, description, citation text, contacts, license, DOI, numConstituents (sub-datasets), and temporal/geographic coverage. Use after gbif_search_datasets or when an occurrence record's datasetKey needs provenance detail.
| Name | Required | Description | Default |
|---|---|---|---|
| datasetKey | Yes | Dataset UUID from gbif_search_datasets or an occurrence record. |
Output Schema
| Name | Required | Description |
|---|---|---|
| doi | No | DOI for citation. May be absent. |
| key | No | Dataset UUID. |
| type | No | Dataset type (OCCURRENCE, CHECKLIST, etc.). |
| title | No | Dataset title. |
| license | No | License identifier. May be absent. |
| contacts | No | Dataset contacts. May be absent. |
| description | No | Full dataset description. May be absent. |
| recordCount | No | Number of records in the dataset. May be absent. |
| citationText | No | Full citation text for academic reference. May be absent. |
| numConstituents | No | Number of constituent sub-datasets. May be absent. |
| publishingCountry | No | Country code of the publishing organization. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is well-covered. The description adds that the tool fetches full metadata and enumerates fields like citation, license, contacts, etc. However, it does not disclose any additional behavioral traits (e.g., rate limits, pagination, or error handling) beyond what annotations imply.
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: first states purpose and lists fields, second provides usage guidance. No fluff, every sentence adds value. Front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present (as indicated), the description appropriately omits return value details. It lists the fields included (title, description, citation text, contacts, license, DOI, numConstituents, temporal/geographic coverage) and explains when to use it. For a simple one-parameter tool, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter datasetKey. The description reiterates the schema's description ('Dataset UUID from gbif_search_datasets or an occurrence record') without adding significant new meaning beyond specifying the source. 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 starts with a specific verb ('Fetch') and noun ('full dataset metadata by UUID key'), then lists the metadata fields included. This clearly differentiates from sibling tools like gbif_search_datasets (search-oriented) and gbif_get_occurrence (occurrence-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'Use after gbif_search_datasets or when an occurrence record's datasetKey needs provenance detail.' Provides context but does not explicitly mention when not to use it or alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gbif_get_occurrenceGet Occurrence RecordARead-onlyIdempotentInspect
Fetch a single occurrence record by its GBIF occurrence key. Returns the complete Darwin Core record — all coordinates, administrative geography (GADM), dates, collections metadata, collector identifiers, media links, and quality issue flags. Use the occurrence key from gbif_search_occurrences results to fetch full detail.
| Name | Required | Description | Default |
|---|---|---|---|
| occurrenceKey | Yes | GBIF occurrence key from gbif_search_occurrences results. |
Output Schema
| Name | Required | Description |
|---|---|---|
| day | No | Observation day. May be absent. |
| key | No | GBIF occurrence key. |
| sex | No | Sex of the individual(s). May be absent. |
| year | No | Observation year. May be absent. |
| genus | No | Genus classification. |
| media | No | Associated media (images, audio, video). May be absent. |
| month | No | Observation month (1–12). May be absent. |
| order | No | Order classification. |
| family | No | Family classification. |
| issues | No | GBIF data quality issue flags. |
| phylum | No | Phylum classification. |
| country | No | Country name. May be absent. |
| kingdom | No | Kingdom classification. |
| species | No | Species canonical name. |
| locality | No | Locality description. May be absent. |
| taxonKey | No | Backbone taxon key. |
| continent | No | Continent name. May be absent. |
| eventDate | No | Observation date as ISO 8601 string. May be absent. |
| lifeStage | No | Life stage of the individual(s). May be absent. |
| taxonRank | No | Taxonomic rank of the identified taxon. |
| datasetKey | No | UUID of the source dataset. |
| recordedBy | No | Collector name(s). May be absent. |
| countryCode | No | ISO 3166-1 alpha-2 country code. May be absent. |
| identifiedBy | No | Identifier name(s). May be absent. |
| basisOfRecord | No | How the occurrence was recorded. |
| canonicalName | No | Canonical name without authorship. |
| catalogNumber | No | Catalog number within the collection. May be absent. |
| stateProvince | No | State or province. May be absent. |
| collectionCode | No | Collection code within the institution. May be absent. |
| scientificName | No | Scientific name from occurrence record. |
| decimalLatitude | No | Latitude in decimal degrees (WGS84). May be absent. |
| individualCount | No | Number of individuals. May be absent. |
| institutionCode | No | Code of the contributing institution. May be absent. |
| decimalLongitude | No | Longitude in decimal degrees (WGS84). May be absent. |
| publishingCountry | No | Country code of the publishing organization. |
| coordinateUncertaintyInMeters | No | Coordinate uncertainty radius in meters. May be absent. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as read-only and idempotent; description adds detailed return content (coordinates, geography, dates, collections, media, quality flags) beyond annotations, giving full behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, every sentence contributes value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter and existing output schema, description provides complete guidance on when to use, what to expect, and how data connects to sibling 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 has 100% coverage with description for single parameter. Description repeats source of key but adds no new semantic information beyond schema, meeting baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a single occurrence record by its GBIF key, specifying the resource and action. It distinguishes from sibling search tool by mentioning use of occurrence key from search results.
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 instructs to use occurrence key from gbif_search_occurrences results, providing clear context for when and how to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gbif_get_speciesGet Species RecordARead-onlyIdempotentInspect
Fetch a single backbone taxon by its GBIF taxon key. Returns full classification, authorship, taxonomic status, vernacular name, descendant count, and publication reference. Use after gbif_match_species when you need the complete record rather than the match summary. When taxonomicStatus is SYNONYM, acceptedKey and accepted fields identify the accepted taxon. The extinct field is absent (not false) on most records — only present on explicitly flagged taxa.
| Name | Required | Description | Default |
|---|---|---|---|
| taxonKey | Yes | GBIF backbone taxon key from gbif_match_species or another taxonomy tool. |
Output Schema
| Name | Required | Description |
|---|---|---|
| key | No | GBIF backbone taxon key. |
| rank | No | Taxonomic rank (SPECIES, GENUS, FAMILY, etc.). |
| class | No | Class classification. |
| genus | No | Genus classification. |
| order | No | Order classification. |
| family | No | Family classification. |
| parent | No | Name of the immediate parent taxon. |
| phylum | No | Phylum classification. |
| extinct | No | True when the taxon is explicitly flagged as extinct. Absent on most records. |
| kingdom | No | Kingdom classification. |
| species | No | Species canonical name. |
| accepted | No | Scientific name of the accepted taxon when this record is a synonym. |
| classKey | No | Taxon key for the class. |
| genusKey | No | Taxon key for the genus. |
| orderKey | No | Taxon key for the order. |
| familyKey | No | Taxon key for the family. |
| parentKey | No | Taxon key of the immediate parent. |
| phylumKey | No | Taxon key for the phylum. |
| authorship | No | Taxonomic authorship of the name. |
| kingdomKey | No | Taxon key for the kingdom. |
| speciesKey | No | Taxon key for the species. |
| acceptedKey | No | Backbone key of the accepted taxon when this record is a synonym. |
| publishedIn | No | Original description citation when available. |
| canonicalName | No | Scientific name without authorship. |
| numDescendants | No | Count of child taxa in the backbone under this taxon. |
| numOccurrences | No | Occurrence record count in GBIF. |
| scientificName | No | Full scientific name with authorship. |
| vernacularName | No | English common name when available. |
| taxonomicStatus | No | ACCEPTED, SYNONYM, DOUBTFUL, etc. SYNONYM means acceptedKey/accepted are populated. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and read-only behavior. Description adds valuable nuance about the extinct field being absent on most records and explains synonym handling beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a distinct purpose: action, return details, usage guidance, and behavioral note. No redundant information, well 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?
Given the presence of an output schema and clear annotations, the description covers all essential aspects: what it fetches, when to use it, and special edge cases (synonyms, extinct field). It is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter taxonKey is fully described in the schema (100% coverage). The description reinforces its origin from gbif_match_species, adding workflow context that slightly exceeds 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?
The description specifies 'Fetch a single backbone taxon' which clearly identifies the action and resource. It distinguishes this tool from siblings like gbif_match_species by noting it returns the complete record rather than a match summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to use after gbif_match_species when a complete record is needed, providing clear orchestration guidance. Also explains behavior for synonyms with acceptedKey and accepted fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gbif_get_species_childrenGet Species ChildrenARead-onlyIdempotentInspect
List direct children of a backbone taxon — genera within a family, species within a genus, subspecies within a species. Paginated. Use gbif_match_species to get the taxonKey first, then iterate with offset for large groups.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of children to return (default 20, max 1000). | |
| offset | No | Pagination offset. | |
| taxonKey | Yes | GBIF backbone taxon key from gbif_match_species or another taxonomy tool. |
Output Schema
| Name | Required | Description |
|---|---|---|
| limit | Yes | Records returned in this page. |
| offset | Yes | Current pagination offset. |
| children | Yes | Direct child taxa. |
| endOfRecords | Yes | True when there are no more results after this page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and idempotency. The description adds the nuance that it returns direct children only, which is a behavioral detail. However, it does not disclose additional traits like rate limits or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence explains purpose; the second provides workflow instructions. Information 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 a list tool with an output schema, the description covers the core functionality and pagination. It could mention support for nested or related tools, but overall it is 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?
Input schema has 100% description coverage, with each parameter explained. The description reinforces the pagination usage but adds little beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists direct children of a backbone taxon, with concrete examples (genera within a family, species within a genus). This distinguishes it from siblings like gbif_get_species_classification (ancestors) and gbif_search_species (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance to use gbif_match_species to get the taxonKey first and to iterate with offset for large groups is provided. While it doesn't explicitly state when not to use, the instructions are clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gbif_get_species_classificationGet Species ClassificationARead-onlyIdempotentInspect
Return the complete parent chain for a taxon — from kingdom (or domain) down to the taxon itself — as an ordered array. Each entry has its rank, canonical name, and taxon key. The array is returned root-first (kingdom → phylum → class → … → parent of given taxon). Useful for building taxonomic trees or understanding placement without navigating the backbone level-by-level.
| Name | Required | Description | Default |
|---|---|---|---|
| taxonKey | Yes | GBIF backbone taxon key from gbif_match_species or another taxonomy tool. |
Output Schema
| Name | Required | Description |
|---|---|---|
| classification | Yes | Classification chain ordered from root (kingdom) to the immediate parent of the queried taxon. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. The description adds behavioral specifics: the array is root-first, includes rank/canonical name/taxon key, and the order from kingdom to the taxon itself. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, directly to the point. The description is front-loaded with the action and key details, with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, an output schema (implied), and simple behavior, the description fully covers what the agent needs to know: input source, output structure and order, and use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the only parameter (taxonKey). The description adds value by specifying the source of the key ('from gbif_match_species or another taxonomy tool'), which helps the agent understand what input is expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the complete parent chain for a taxon as an ordered array, listing each entry's rank, canonical name, and taxon key. It uses specific verbs ('Return') and distinguishes itself from siblings like gbif_get_species_children by focusing on the lineage upward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains it is useful for building taxonomic trees or understanding placement without navigating level-by-level. While it does not explicitly state when not to use it or compare to siblings, the context provided is clear enough for an agent to infer appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gbif_match_speciesMatch Species NameARead-onlyIdempotentInspect
Match a scientific name against the GBIF backbone taxonomy. Returns the best-matching taxon with full classification and a confidence score (0–100). This is the mandatory first step for any GBIF workflow — it resolves synonyms and returns the backbone taxonKey required by gbif_search_occurrences, gbif_count_occurrences, and gbif_occurrence_facets. Below confidence 80, the match should be reviewed. matchType NONE means no usable match was found — try removing the strict flag or broadening the name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Scientific name to match. Examples: "Parus major", "Agaricus bisporus", "Homo sapiens". Fuzzy matching handles minor spelling variations. Common names are not supported — use gbif_search_species for vernacular name searches. | |
| rank | No | Expected taxonomic rank. Use to avoid matching a genus when you expect a species. | |
| strict | No | When true, only return an exact match. When false (default), GBIF applies fuzzy matching — useful for minor spelling variations and abbreviated names. | |
| kingdom | No | Narrow the match to a specific kingdom (e.g., "Animalia", "Plantae", "Fungi") to disambiguate names that appear in multiple kingdoms. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rank | No | Taxonomic rank of the matched taxon. |
| class | No | Class of the matched taxon. |
| genus | No | Genus of the matched taxon. |
| order | No | Order of the matched taxon. |
| family | No | Family of the matched taxon. |
| phylum | No | Phylum of the matched taxon. |
| status | No | Taxonomic status: ACCEPTED, SYNONYM, or DOUBTFUL. |
| kingdom | No | Kingdom of the matched taxon. |
| species | No | Species canonical name of the matched taxon. |
| classKey | No | Backbone taxon key for the class. |
| genusKey | No | Backbone taxon key for the genus. |
| orderKey | No | Backbone taxon key for the order. |
| taxonKey | No | GBIF backbone taxon key. Use this in downstream tools. Absent when matchType is NONE. |
| familyKey | No | Backbone taxon key for the family. |
| matchType | No | EXACT, FUZZY, HIGHERORDER, or NONE. NONE means no usable match. |
| phylumKey | No | Backbone taxon key for the phylum. |
| confidence | No | Match confidence score 0–100. Below 80 warrants review. |
| kingdomKey | No | Backbone taxon key for the kingdom. |
| speciesKey | No | Backbone taxon key for the species. |
| canonicalName | No | Scientific name without authorship. |
| scientificName | No | Full scientific name with authorship. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. Description adds behavioral context: mandatory workflow step, fuzzy matching behavior, confidence interpretation, and error recovery suggestions. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Approximately 5 sentences, front-loaded with main purpose. Each sentence adds value (purpose, workflow position, error handling). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (4 parameters, output schema exists) and annotations present, description is thorough: covers mandatory nature, confidence interpretation, error cases, and sibling differentiation. Output schema handles return values.
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 covers all 4 parameters with descriptions (100% coverage). Description adds minimal parameter context beyond schema, mentioning fuzzy matching for name and rank usage advice. 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?
Clearly states the verb 'Match', resource 'scientific name against GBIF backbone taxonomy', and return value 'best-matching taxon with full classification and confidence score'. Distinguishes from sibling gbif_search_species by noting common names are not supported.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'mandatory first step for any GBIF workflow' and names downstream tools requiring the returned taxonKey. Provides guidance on confidence thresholds (below 80) and error handling (matchType NONE suggests removing strict flag or broadening name).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gbif_occurrence_facetsOccurrence Facet AggregationARead-onlyIdempotentInspect
Aggregate occurrence counts across a dimension (COUNTRY, YEAR, BASIS_OF_RECORD, DATASET_KEY, KINGDOM_KEY, etc.). Returns the top-N facet values ranked by count — no record payloads returned. Core tool for distribution analysis and trend queries: "which countries have the most records for this species?", "how has observation volume changed since 2010?". Scope the aggregation with taxonKey, country, year, geometry, or basisOfRecord filters.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year or year range (e.g., "2020,2024") to scope the aggregation. | |
| facet | Yes | Dimension to aggregate by (e.g., COUNTRY, YEAR, BASIS_OF_RECORD, SPECIES_KEY). | |
| country | No | ISO 3166-1 alpha-2 country code to scope to one country. | |
| geometry | No | WKT polygon to scope the aggregation to a geographic area (e.g., POLYGON((8 47, 9 47, 9 48, 8 48, 8 47))). Coordinates are longitude latitude. | |
| taxonKey | No | Backbone taxon key to scope the aggregation. | |
| facetLimit | No | Maximum number of facet values to return (default 10, max 100). | |
| basisOfRecord | No | Scope to a specific basis of record. |
Output Schema
| Name | Required | Description |
|---|---|---|
| facet | Yes | The facet dimension aggregated. |
| counts | Yes | Facet values ranked by count descending (top facetLimit entries). |
| totalOccurrences | Yes | Total matching occurrences across all facet values. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. The description adds that only counts are returned (no record payloads) and that results are top-N ranked by count, which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences covering core function, return format, and use cases. No wasted words; key information 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?
Given the output schema exists, return values need not be explained. The description covers purpose, scoping, and use cases. Missing details like handling of no results are 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 description coverage is 100%, so baseline is 3. The description adds general scoping guidance but does not significantly add meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Aggregate occurrence counts across a dimension' with specific examples like COUNTRY, YEAR, BASIS_OF_RECORD. It distinguishes from siblings by noting 'no record payloads returned', making it unique among tools that could return full records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: distribution analysis and trend queries, with example questions. It mentions scoping filters but does not explicitly list when not to use or name alternative tools, though the context implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gbif_search_datasetsSearch DatasetsARead-onlyIdempotentInspect
Search GBIF datasets by keyword, type, country, or publishing organization. Returns dataset title, description, license, record count, and DOI. Use to find the source dataset behind a set of records, or to explore what data collections are available for a taxon, country, or organization.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text search across dataset title and description. | |
| type | No | Filter by dataset type. OCCURRENCE for observation records, CHECKLIST for species lists. | |
| limit | No | Number of datasets to return (default 20, max 1000). | |
| offset | No | Pagination offset. | |
| hostingOrg | No | UUID of the hosting organization. From gbif_search_publishers results. | |
| publishingCountry | No | ISO 3166-1 alpha-2 country code of the publishing organization. |
Output Schema
| Name | Required | Description |
|---|---|---|
| limit | Yes | Datasets returned in this page. |
| offset | Yes | Current pagination offset. |
| datasets | Yes | Matching datasets. |
| totalCount | Yes | Total matching datasets before pagination. |
| endOfRecords | Yes | True when there are no more results after this page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint) already indicate safe, idempotent behavior. The description adds that it returns dataset summaries (title, description, license, etc.) and is a search operation. No contradiction, and it provides useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and return fields, second gives use cases. Extremely concise with no wasted words. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 6 optional parameters and an output schema, the description covers why to use it and what it returns. It does not detail error handling or rate limits, but that is acceptable for this context. Sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds a general overview but no additional parameter-specific details beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and resource 'GBIF datasets' with specific filters (keyword, type, country, organization) and return fields (title, description, license, record count, DOI). It distinguishes from siblings like gbif_get_dataset (single dataset) and gbif_search_occurrences (occurrences).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use to find the source dataset behind a set of records, or to explore what data collections are available for a taxon, country, or organization.' It does not list exclusions or alternatives, but the context makes alternatives clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gbif_search_occurrencesSearch OccurrencesARead-onlyIdempotentInspect
Search 2.4B+ GBIF occurrence records with Darwin Core filters. Use taxonKey from gbif_match_species for reliable results — it resolves synonyms automatically. Accepts country (ISO 3166-1 alpha-2), bounding box (decimalLatitude/decimalLongitude ranges), WKT polygon geometry, year range, month, basis of record, and coordinate filter. Pagination is capped at approximately offset+limit=100,000 — use gbif_occurrence_facets for aggregate counts across large result sets.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year or year range. Single year: "2024". Range: "2020,2024". Filters by observation year. | |
| limit | No | Number of records to return (default 20, max 300). | |
| month | No | Calendar month (1–12). Useful for seasonal distribution queries. | |
| offset | No | Pagination offset. GBIF caps offset+limit at approximately 100,000 — use gbif_occurrence_facets for aggregate analysis beyond this. | |
| country | No | ISO 3166-1 alpha-2 country code (e.g., "GB", "US", "DE", "SE"). | |
| geometry | No | WKT polygon for geographic filtering (e.g., POLYGON((8 47, 9 47, 9 48, 8 48, 8 47))). Coordinates are longitude latitude. Takes precedence over decimalLatitude/decimalLongitude. | |
| taxonKey | No | GBIF backbone taxon key from gbif_match_species. Preferred over scientificName — matches all synonyms automatically. | |
| isInCluster | No | Filter to records flagged as likely duplicates (true) or exclude them (false). Omit to include all. | |
| basisOfRecord | No | Filter by how the occurrence was recorded. HUMAN_OBSERVATION covers citizen science. PRESERVED_SPECIMEN covers natural history collections. | |
| hasCoordinate | No | When true, return only georeferenced records. When false, include records without coordinates. | |
| scientificName | No | Scientific name filter. Less precise than taxonKey — does not match synonyms. Use taxonKey from gbif_match_species for reliable results. | |
| decimalLatitude | No | Latitude range as "min,max" (e.g., "47.0,48.5"). Decimal degrees, WGS84. Combine with decimalLongitude for a bounding box. | |
| decimalLongitude | No | Longitude range as "min,max" (e.g., "8.0,9.5"). Decimal degrees, WGS84. Combine with decimalLatitude for a bounding box. |
Output Schema
| Name | Required | Description |
|---|---|---|
| limit | Yes | Records returned in this page. |
| offset | Yes | Current pagination offset. |
| totalCount | Yes | Total matching occurrences before pagination. |
| occurrences | Yes | Occurrence records matching the filters. |
| endOfRecords | Yes | True when there are no more results after this page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation indicates readOnlyHint, idempotentHint – description adds pagination cap (100k), filter precedence (geometry over decimalLatitude/decimalLongitude), and links to faceted search for large sets, providing context beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences – purpose, filters, pagination guidance – each sentence adds value, front-loaded with key points, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema existence and 13 parameters (0 required), description covers purpose, key filter types, pagination limit, alternative for large aggregates, and filter precedence – adequate for effective tool selection.
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 detailed descriptions; description lists filter types but does not add significant parameter-level details beyond the schema's existing documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Search 2.4B+ GBIF occurrence records with Darwin Core filters', specifying verb, resource, and scope. Distinguishes from siblings by referencing gbif_occurrence_facets for aggregations and gbif_match_species for reliable taxonKey usage.
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 guides when to use this tool versus alternatives: recommends taxonKey over scientificName, warns that offset+limit is capped at 100k and suggests gbif_occurrence_facets for larger queries. Also notes that geometry takes precedence over coordinate ranges.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gbif_search_publishersSearch PublishersARead-onlyIdempotentInspect
Search organizations registered with GBIF by name fragment or country. Returns organization key, title, and country — sufficient to chain into gbif_search_datasets with hostingOrg, or to understand who publishes data for a region.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Name fragment to search for. Matches organization names. | |
| limit | No | Number of organizations to return (default 20, max 1000). | |
| offset | No | Pagination offset. | |
| country | No | ISO 3166-1 alpha-2 country code to filter organizations by country. |
Output Schema
| Name | Required | Description |
|---|---|---|
| limit | Yes | Organizations returned in this page. |
| offset | Yes | Current pagination offset. |
| publishers | Yes | Matching organizations. |
| totalCount | Yes | Total matching organizations before pagination. |
| endOfRecords | Yes | True when there are no more results after this page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds that it returns organization key, title, and country, which are not in annotations. No contradictions. Adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information, front-loaded with purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description still provides a concise summary of return values. For a simple search tool, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all parameters. Description does not add additional parameter details beyond schema, which is acceptable. Baseline score of 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?
Description explicitly states the tool searches organizations registered with GBIF by name fragment or country, and specifies the returned fields (key, title, country). It distinguishes from siblings by mentioning chaining to gbif_search_datasets with hostingOrg.
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 context on when to use: to find organizations for dataset searching or to understand regional publishers. Implicitly suggests not to use for detailed dataset searches. Could include explicit when-not-to-use, but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gbif_search_speciesSearch Species TaxonomyARead-onlyIdempotentInspect
Search or browse the GBIF backbone taxonomy. Accepts scientific name fragments, rank filters, and higher-taxon constraints. Useful for exploring what species exist under a higher taxon (e.g., "list all families of Coleoptera"), for simple name-fragment searches, or when gbif_match_species returns too narrow a result. Paginated — use limit and offset to walk through results.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Name fragment to search for. Matches scientific and vernacular names. | |
| rank | No | Filter to a specific taxonomic rank. | |
| genus | No | Scope search to a genus name. | |
| limit | No | Number of records to return (default 20, max 1000). | |
| family | No | Scope search to a family name. | |
| offset | No | Pagination offset. | |
| kingdom | No | Scope search to a kingdom (e.g., "Animalia", "Plantae"). | |
| isExtinct | No | Filter to extinct (true) or extant (false) taxa. | |
| datasetKey | No | Scope to a specific checklist dataset UUID. Omit to search the GBIF backbone. |
Output Schema
| Name | Required | Description |
|---|---|---|
| taxa | Yes | Matching taxa. |
| limit | Yes | Records returned in this page. |
| offset | Yes | Current pagination offset. |
| totalCount | Yes | Total matches before pagination. |
| endOfRecords | Yes | True when there are no more results after this page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, idempotentHint, and openWorldHint. The description adds value by explaining pagination behavior and that the tool is for searching/browsing, which aligns with the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three well-structured sentences. It front-loads the main purpose and provides key use cases without extraneous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no required, output schema exists), the description covers main use cases and pagination. It references a sibling tool and explains when to use this tool, making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds overall context by mentioning accepted inputs (name fragments, rank filters, higher-taxon constraints) and explaining limit/offset for pagination, which provides additional 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?
The description clearly states the tool's purpose: searching or browsing the GBIF backbone taxonomy. It lists specific use cases like exploring species under higher taxa and name-fragment searches, and distinguishes from sibling tool gbif_match_species by noting when this tool is more appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: useful for exploring species under higher taxa, simple name-fragment searches, or when gbif_match_species returns narrow results. It mentions pagination but does not explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!