Skip to main content
Glama
tyson-swetnam

gbif-mcp

by tyson-swetnam
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

gbif_occurrence_download_request

Request asynchronous downloads for large GBIF occurrence datasets exceeding pagination limits (100,000+ records). Returns a download key to check status; requires authentication.

Instructions

Request an asynchronous download for large occurrence datasets beyond pagination limits (100,000+ records). Returns a download key for checking status. REQUIRES AUTHENTICATION: Set GBIF_USERNAME and GBIF_PASSWORD environment variables.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNoDownload format. DWCA (Darwin Core Archive) = Full format with metadata and extensions, most comprehensive. SIMPLE_CSV = Simplified CSV format, easier to work with in spreadsheets. SPECIES_LIST = List of unique species only, no occurrence records. Default: SIMPLE_CSV.SIMPLE_CSV
creatorYesGBIF username (creator of the download). This is your GBIF.org username. Example: "john.smith". Required for download attribution and access control.
predicateNoDownload predicate defining filters (REQUIRED). Complex JSON structure specifying which records to include. Use gbif_occurrence_download_predicate_builder tool to construct this from simple search parameters, or build manually following GBIF download API predicate format. Example: {type: "equals", key: "TAXON_KEY", value: "212"} for all bird records.
sendNotificationNoSend email notification on completion. Set to true (default) to receive email when download is ready, false to skip notifications. Recommended: true for downloads that take more than a few minutes.
notificationAddressesNoEmail addresses to notify when download completes. Receives notification with download link when processing is finished. Example: ["user@example.com"]. Optional, but highly recommended for large downloads that may take hours to process.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.2/5.0
Behavior4/5

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

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

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

Conciseness5/5

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

Three tight sentences with zero waste: purpose and scope first, return behavior second, authentication requirement last. The most decision-relevant constraint (large datasets / async) is front-loaded.

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

Completeness4/5

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

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

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

Parameters3/5

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

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

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

Purpose5/5

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

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

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

Usage Guidelines4/5

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

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

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

Deploy Server

Other Tools