gbif-mcp-server
Server Details
Search GBIF species taxonomy, occurrence records, datasets, and publishers.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/gbif-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.5/5 across 12 of 12 tools scored.
Each tool clearly targets a distinct operation on a specific resource type (occurrences, species, datasets, publishers). For example, count_occurrences, search_occurrences, and occurrence_facets serve different purposes (counting, searching, aggregating), and get_species vs search_species vs match_species are well-differentiated. No two tools have overlapping functionality.
All tools use the 'gbif_' prefix and mostly follow a verb_noun pattern (e.g., gbif_count_occurrences, gbif_get_dataset, gbif_search_occurrences). The only minor deviation is gbif_occurrence_facets, which places the verb second; however, the pattern is still highly recognizable and consistent overall.
With 12 tools covering search, retrieval, counting, faceting, and matching across occurrences, species, datasets, and publishers, the tool count is well-proportioned to the server's purpose. Each tool addresses a specific need without redundancy or bloat.
The tool set covers the essential GBIF operations: name resolution (match_species), occurrence search and counting (search_occurrences, count_occurrences, occurrence_facets), species taxonomy (get_species, get_species_children, get_species_classification, search_species), dataset and publisher metadata (search_datasets, get_dataset, search_publishers), and detailed occurrence records (get_occurrence). No obvious dead ends or missing operations 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"). | |
| 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 and idempotentHint true, so safety is clear. Description adds that counts are without fetching records, but otherwise does not disclose additional behavioral details beyond 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 sentences with no unnecessary words. Purpose is front-loaded, and the example adds clarity without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the availability of an output schema (not shown but indicated), the description sufficiently covers purpose, use case, and parameters. Could mention if count is approximate, but not essential.
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. Description lists parameter names but adds no additional meaning or example values beyond what schema provides.
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 'Count occurrences' (verb+resource) and distinguishes from fetching by 'without fetching records'. Includes concrete examples ('how many Aves records in Sweden?') and differentiates from sibling search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states use for 'quick totals' and 'before deciding whether to paginate a full search', providing clear usage context. Does not explicitly mention when not to use, but the alternative is implied.
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=true and idempotentHint=true. The description adds value by listing the metadata fields returned (title, citation, contacts, etc.), which provides useful behavioral context 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?
Two sentences: the first states the core function and outputs, the second gives usage context. Every word is purposeful, 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?
With only one parameter and an output schema (assumed present), the description adequately covers what the tool does, what it returns, and when to use it. No gaps identified.
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 datasetKey is well-described in the schema as 'Dataset UUID...'. The description adds extra context by specifying it comes from gbif_search_datasets or an occurrence record, enhancing understanding 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?
Description clearly states 'Fetch full dataset metadata by UUID key' and lists specific fields returned. It distinguishes from sibling tools by explicitly saying to use after gbif_search_datasets or when needing provenance detail for a datasetKey.
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 after gbif_search_datasets or when an occurrence record's datasetKey needs provenance detail.' Does not explicitly state when not to use, but the guidance is sufficient for correct tool selection.
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 declare readOnlyHint=true and idempotentHint=true. Description adds value by detailing return fields (coordinates, GADM, dates, etc.) and quality flags, informing agent of data richness. 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, no superfluous words. First sentence states action and key, second enumerates return components and usage guidance. Very efficient.
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 (1 param, read-only, idempotent) and presence of an output schema, description provides adequate context: workflow from sibling tool, range of return fields. No gaps for safe usage.
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?
Single parameter occurrenceKey is fully described in input schema with 100% coverage. Description reinforces schema but does not add new semantic information beyond what schema provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it fetches a single occurrence by key. Distinguishes from sibling search tool by specifying use of output key from gbif_search_occurrences. Lists return content (Darwin Core fields), providing specific verb and resource.
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, establishing a clear workflow. No explicit when-not-to-use, but context from sibling names indicates alternatives for counting or other searches.
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 readOnly and idempotent. Description adds beyond: returns full classification, authorship, taxonomic status, etc. Also explains synonym handling and extinct field behavior, which annotations do not cover.
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, each serving a distinct purpose: purpose/what returned, usage guidance, behavioral note. No wasted words, 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 single parameter, high schema coverage, rich annotations, and output schema, the description covers all necessary context: when to use, what returns, key behavioral nuances.
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 only parameter 'taxonKey' is fully described in schema. The description adds provenance context ('from gbif_match_species or another taxonomy tool'), providing 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 starts with a specific verb 'Fetch' and the resource 'single backbone taxon by its GBIF taxon key'. It clearly distinguishes from sibling gbif_match_species by stating it is used after that tool for a complete record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use after gbif_match_species when you need the complete record rather than the match summary.' This provides clear context and differentiates from sibling.
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 and idempotentHint. Description adds pagination behavior (limit, 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?
Three sentences, front-loaded with purpose, no wasted words. Efficient and clear.
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?
Output schema exists, so return values are covered. Description covers usage pattern and pagination. Enough for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 applies. Description adds the context that taxonKey comes from gbif_match_species but doesn't provide additional semantics beyond 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?
Description uses specific verb 'List' and resource 'direct children of a backbone taxon', with concrete examples (genera within a family, etc.). Clearly distinguishes from siblings by implying children vs. classification or match.
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 prerequisite to use gbif_match_species first and mentions pagination with offset. Lacks explicit when-not or alternatives, but the context is clear.
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?
Discloses that the array is ordered root-first, which is key behavioral info not in annotations. Adds context about entry content (rank, name, key). No contradiction with 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?
Concise, front-loaded with the main purpose, and no extraneous information. 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 presence of an output schema, the description adequately covers return format and ordering. Provides sufficient context for usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, description adds value by specifying the source of the taxon key (e.g., gbif_match_species), aiding parameter selection.
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 action: 'Return the complete parent chain for a taxon.' Differentiates from siblings by specifying it returns the ancestor chain, not children or matching.
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 a clear use case: 'building taxonomic trees or understanding placement.' Implicitly suggests when to use but does not explicitly exclude alternatives or mention when not to use.
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 misspellings and vernacular 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 (readOnlyHint, idempotentHint) already indicate no side effects. Description supplements with synonym resolution, fuzzy matching, strict flag behavior, and match type interpretation. 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?
Compact 4-sentence description. Front-loaded with core function, then key usage and edge cases. Every sentence adds value without 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?
Complete for a lookup tool with good annotations and output schema. Covers mandatory usage, confidence handling, fallback behavior, and sibling differentiation. No gaps.
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 descriptions for all params. Description adds value with examples for 'name', explains 'rank' enum purpose, and clarifies 'strict' and 'kingdom' usage. 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?
Clear verb 'Match' and specific resource 'scientific name against GBIF backbone taxonomy'. Differentiates from siblings like gbif_search_species (vernacular name search) and gbif_search_occurrences (needs taxonKey).
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 lists downstream tools requiring the returned taxonKey. Provides guidance on confidence threshold (<80) and matchType NONE escalation. Mentions alternative for vernacular names.
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 readOnly and idempotent. The description adds that it returns only counts (no records) and ranked top-N facet values, providing 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?
Three concise sentences with no superfluous information. Front-loaded with the core function and examples.
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 7 parameters and an output schema, the description covers purpose, usage guidance, and key behaviors. It is complete enough for an agent to decide when to invoke 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 baseline is 3. The description lists filter options collectively but doesn't add significant new semantics beyond the schema 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 it aggregates occurrence counts across dimensions like COUNTRY, YEAR, etc., and returns top-N values. It distinguishes from siblings like search_occurrences by stating 'no record payloads returned', making its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it's the 'core tool for distribution analysis and trend queries' and gives example questions. Implies when to use this tool over record-level searches, though does not explicitly list alternatives.
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 already declare readOnlyHint=true and idempotentHint=true, so the tool's safety is clear. The description adds that it returns specific fields, which is useful but not required beyond 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 two sentences: first sentence covers action and return fields, second gives use cases. It is front-loaded and concise, with 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 6 parameters, an output schema, and no required params, the description covers the tool's purpose and return fields. It could mention pagination or result ordering, but is largely complete for a search 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% with detailed parameter descriptions (e.g., type enum explanations). The description mentions keyword, type, country, and organization, aligning with schema, but adds no extra meaning beyond that. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search GBIF datasets by keyword, type, country, or publishing organization' with a clear verb and resource. It lists return fields and provides use cases, effectively distinguishing from siblings like gbif_get_dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit contexts for use: 'find the source dataset behind a set of records' or 'explore what data collections are available.' However, it does not mention when not to use it or point to alternatives like gbif_get_dataset for specific datasets.
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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. Description adds valuable behavioral details: pagination cap behavior, taxonKey resolves synonyms automatically, geometry takes precedence over coordinates, and specific basisOfRecord examples. No contradictions with 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?
Three sentences, each serving a purpose: first explains core function and filter range, second gives usage tip and enumerates filters, third notes pagination limit and alternative. Front-loaded with key information, 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?
Tool has 13 parameters and an output schema exists (so return format is handled). Description covers essential behaviors: pagination cap, taxon resolution, filter interactions, and links to sibling tools. Could mention default behavior if no filters provided, but overall complete for a complex 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?
All 13 parameters have descriptions in the schema (100% coverage). Description adds context beyond schema: explains that country uses ISO 3166-1 alpha-2, geometry precedence over decimalLatitude/decimalLongitude, taxonKey preferred over scientificName, and examples for basisOfRecord (e.g., 'HUMAN_OBSERVATION covers citizen science').
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 'Search 2.4B+ GBIF occurrence records with Darwin Core filters', specifying verb (search), resource (occurrence records), and scope (2.4B+ records, Darwin Core filters). It also distinguishes from siblings by mentioning gbif_occurrence_facets for aggregate counts and gbif_match_species for taxon matching.
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 explicit guidelines: use taxonKey from gbif_match_species for reliable results, pagination cap at approximately offset+limit=100,000, and advises using gbif_occurrence_facets for aggregate analysis beyond this cap. Clearly states when to use this tool and when to use the alternative.
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=true and idempotentHint=true, so the description does not need to repeat safety traits. It adds value by stating that the tool returns sufficient information for chaining, which is a behavioral clue beyond 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 a single, well-structured sentence that front-loads the action and key return fields. Every clause earns its place, providing purpose, parameters, and usage guidance without verbosity.
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 moderate complexity (4 parameters, no required, output schema present), the description completely covers the necessary context: what it does, what it returns, and how to use it in a workflow. No gaps remain.
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 description adds little beyond what the schema already provides for parameters. The description reiterates that 'q' matches organization names and 'country' is an ISO code, but this is already in the schema. No new semantic meaning is added.
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 searches organizations by name fragment or country, and specifies the return fields (key, title, country). It distinguishes itself from sibling tools like gbif_search_datasets by highlighting that it can be chained with that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: to search for publishers, and how to chain results into gbif_search_datasets using hostignOrg. It also gives the alternative purpose of understanding who publishes data for a region, providing clear context for use.
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?
The description discloses pagination behavior (use limit and offset) and that it searches the backbone taxonomy, adding value beyond the readOnlyHint and idempotentHint 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 three tightly packed sentences, each earning its place: purpose, usage guidance, and pagination detail. Front-loaded and efficient.
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 complexity (9 parameters with full schema coverage, output schema present), the description covers purpose, usage scenarios, pagination, and sibling differentiation. No gaps for a search tool of this kind.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the description adds some value by clarifying that q matches both scientific and vernacular names, and provides an example use with rank. It slightly enhances understanding 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 searches or browses the GBIF backbone taxonomy, lists accepted inputs (name fragments, rank filters, higher-taxon constraints), and distinguishes itself from the sibling gbif_match_species by noting it is useful when that tool returns too narrow a result.
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 provides use cases (exploring species under a higher taxon, simple name-fragment searches) and contrasts with the sibling gbif_match_species, guiding when to use this tool instead.
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!