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.6/5 across 12 of 12 tools scored.
Each tool targets a distinct operation (search, count, get, match, facets) on a specific resource (occurrences, species, datasets, publishers). There is no ambiguity between tools like gbif_search_occurrences and gbif_count_occurrences or gbif_get_species and gbif_match_species.
All tools follow a strict 'gbif_<verb>_<noun>' pattern with consistent verb choice (get, search, count, match). This makes the tool surface predictable and easy to navigate.
With 12 tools, the set is well-scoped for a biodiversity data API. It provides essential CRUD-like operations for occurrences and taxonomy, plus dataset and publisher discovery, without being overwhelming.
The tool set covers the main GBIF workflows: species matching, occurrence search/count/facets, dataset metadata retrieval, and publisher lookup. Minor gaps exist (e.g., no direct publisher detail by key, no occurrence download tool), but the surface is largely complete for typical biodiversity queries.
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"). Both endpoints inclusive. | |
| country | No | ISO 3166-1 alpha-2 country code (e.g., "GB", "US"). | |
| taxonKey | No | GBIF backbone taxon key from gbif_match_species. Matches the given taxon and all descendant taxa (subspecies, varieties, etc.). | |
| 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 declare readOnlyHint and idempotentHint, meaning the tool is safe and idempotent. The description reinforces this by stating it 'Counts... without fetching records,' and adds no contradictory or additional behavioral risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the main action in the first sentence and usage guidance in the second. No unnecessary words, making it efficient and easy to parse.
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 and parameters are well-documented, the description provides sufficient context for a count-only tool. It covers purpose, usage scenarios, and accepts common filters.
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?
All 5 parameters are fully documented in the input schema (100% coverage). The description adds value by listing the key parameters and giving an example ('how many Aves records in Sweden?'), which aids parameter combination understanding.
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 counts occurrences matching a taxon and location filter without fetching records, which distinguishes it from sibling tools like gbif_search_occurrences that fetch 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 gives explicit use cases: 'Use for quick totals... or before deciding whether to paginate a full search.' This provides clear context, though it could explicitly mention when not to use (e.g., when record details are needed).
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. |
| notice | No | Guidance when no children are found for a valid taxon. Absent on successful result pages. |
| offset | Yes | Current pagination offset. |
| children | Yes | Direct child taxa. |
| totalCount | Yes | Total direct children 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?
Description aligns with annotations (readOnlyHint, idempotentHint) and adds behavioral details: paginated, direct children only, and suggestion to iterate with offset. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and examples, followed by usage guidance. No redundant or unnecessary 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 the tool's simplicity (3 parameters, output schema exists), description covers all essential aspects: what it lists, pagination, prerequisites, and workflow. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes all three parameters with 100% coverage. Description does not add new semantic meaning beyond reinforcing the use of offset for pagination. 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?
Description clearly states the tool lists direct children of a backbone taxon with specific examples (genera within family, species within genus). Distinguishes from siblings like gbif_get_species_classification by emphasizing 'direct' versus parent chain.
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 first use gbif_match_species to obtain taxonKey, then use this tool with offset for large groups. Provides clear step-by-step guidance and mentions pagination, leaving no ambiguity about workflow.
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, STATE_PROVINCE, 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. Both endpoints inclusive. | |
| 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. Matches the given taxon and all descendant taxa (subspecies, varieties, etc.). | |
| 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). |
| notice | No | Guidance when no facet values were returned. Absent when counts are non-empty. |
| facetLimit | Yes | Maximum facet values requested. |
| 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 declare readOnlyHint=true and idempotentHint=true, indicating safe, non-destructive, repeatable behavior. The description adds that the tool returns top-N values by count and no record payloads, which aligns with the annotations. It does not introduce any behavioral contradictions or ambiguities.
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 (3 sentences) and well-structured, with the main action and key purpose in the first sentence. Every sentence adds value, and there is no redundant or 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's complexity (7 parameters, 1 required, output schema present, 12 siblings), the description adequately covers purpose, usage context, and filtering options. It does not need to explain return values since an output schema exists. The annotations and schema handle the rest, making the description complete for a well-documented 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 the schema already documents each parameter. The description provides a high-level overview and lists example dimensions but does not add significant parameter-specific semantics beyond what the schema offers. 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 that the tool aggregates occurrence counts across a dimension (e.g., COUNTRY, YEAR) and returns top-N facet values, explicitly noting 'no record payloads returned.' It provides specific examples of use cases (e.g., 'which countries have the most records for this species?'), distinguishing it from sibling tools like gbif_search_occurrences and gbif_count_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 includes explicit usage context, calling it a 'core tool for distribution analysis and trend queries' and giving example questions. It also notes how to scope the aggregation with filters. However, it does not explicitly mention when not to use the tool or point to alternative tools for other needs (e.g., getting actual records or simple counts without facets).
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. |
| notice | No | Guidance when results are empty or paging overshot. Absent on successful result pages. |
| 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 already declare readOnlyHint and idempotentHint; description adds useful context about return fields (title, description, license, count, DOI), complementing 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 concise sentences, front-loaded with action, 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?
Complete for a search tool: covers what it does, what it returns, and when to use, given annotations and 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 covers 100% of parameters with descriptions; description lists filter criteria and return fields, adding value beyond schema by clarifying output 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?
Description specifies 'Search GBIF datasets' with clear filter criteria and return fields, distinguishing it from sibling tools like gbif_get_dataset or gbif_search_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?
Provides concrete use cases ('find source dataset', 'explore collections'), but does not explicitly state when not to use or mention alternatives from siblings.
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. Both endpoints inclusive. | |
| 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. Matches the given taxon and all descendant taxa (subspecies, varieties, etc.). | |
| isInCluster | No | Filter to records flagged as likely duplicates (true) or exclude them (false). Omit to include all. Note: GBIF does not expose a cluster identifier — only the membership flag. To de-duplicate, set isInCluster: false to exclude all clustered records. | |
| 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. | |
| coordinateUncertaintyInMeters | No | Filter by coordinate uncertainty radius in meters. Range format: "min,max" (e.g., "0,1000" for sub-kilometer precision). Both endpoints inclusive. |
Output Schema
| Name | Required | Description |
|---|---|---|
| limit | Yes | Records returned in this page. |
| notice | No | Guidance when results are empty or paging overshot. Absent on successful result pages. |
| 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?
Description adds value beyond annotations: notes pagination limits, geometry precedence, taxonKey descendant matching, and isInCluster de-duplication advice. Annotations (readOnlyHint, openWorldHint, idempotentHint) are not contradicted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph is well-organized: first sentence states purpose and scale, second gives best practice, then lists key filters, finally notes pagination cap and alternative. 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 14 parameters, 100% schema coverage, and an output schema, the description covers all essential aspects: core filtering parameters, usage constraints, and sibling tool references. Missing output details are compensated by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds critical context: geometry overrides decimalLat/decimalLon, taxonKey matches synonyms/descendants, offset+limit cap, and isInCluster usage. This significantly enhances parameter understanding.
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 opens with 'Search 2.4B+ GBIF occurrence records with Darwin Core filters', clearly stating the verb, resource, and scope. It distinguishes from sibling tools like gbif_occurrence_facets and gbif_match_species, providing precise context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using taxonKey from gbif_match_species for reliable synonym resolution. Warns about pagination cap of 100,000 and directs to gbif_occurrence_facets for aggregate counts, giving clear when-to-use and 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.
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. |
| notice | No | Guidance when results are empty or paging overshot. Absent on successful result pages. |
| 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 value by specifying the exact return fields (organization key, title, country), 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?
Two sentences: first states purpose and parameters, second states return and usage. 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 the tool's simplicity, annotations, and output schema presence, the description covers all necessary aspects: what it searches, how to use results, and chaining context.
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% description coverage, so description adds limited new meaning. Mentions 'name fragment' and 'country' but doesn't significantly extend schema 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 the action ('Search') and resource ('organizations registered with GBIF') and distinguishes from siblings by mentioning chaining to gbif_search_datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use to get publisher info for chaining into dataset search or understanding regional publishing. Does not explicitly state when not to use, but context is 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. |
| notice | No | Guidance when results are empty or paging overshot. Absent on successful result pages. |
| 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 already indicate readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the tool is safe and non-destructive. The description adds value by noting the paginated nature ('Paginated — use limit and offset') and the scope of search (backbone taxonomy). This gives the agent an accurate behavioral model beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no wasted words. The first sentence states the core purpose, and the second sentence gives usage context and pagination details. Every sentence earns its place, making it easy for an agent to parse quickly.
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 9 parameters, an output schema, and several siblings, the description provides sufficient context: purpose, typical use cases, relationship to gbif_match_species, and pagination mechanism. The output schema likely covers return structure, so no further explanation is needed. The description adequately equips an agent to decide whether to use this 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 the baseline is 3. The description summarizes the role of key parameters (name fragments, rank filters, higher-taxon constraints) but does not add significant new meaning beyond what the schema already provides. For example, it mentions 'higher-taxon constraints' which correspond to genus, family, kingdom parameters, but this is already clear from the schema 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 the tool's purpose: 'Search or browse the GBIF backbone taxonomy.' It specifies the types of inputs accepted (scientific name fragments, rank filters, higher-taxon constraints) and explicitly distinguishes it from the sibling tool gbif_match_species, which returns narrower results. The verb 'search' and resource 'GBIF backbone taxonomy' are specific and 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?
The description provides explicit guidance on when to use this tool: for exploring species under a higher taxon, simple name-fragment searches, or when gbif_match_species returns too narrow a result. It mentions pagination with limit and offset. However, it does not explicitly state when not to use it or list alternatives beyond gbif_match_species, which keeps it from a perfect score.
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!