gbif-mcp

waarnemingen

Query species observations in Belgium by location (address, radius, coordinates, region) and time period. Returns totals, sampled observations, and breakdowns by year and dataset.

Instructions

Waarnemingen van één soort in een gebied en periode (GBIF, België), met datum, locatie, dataset en URL.

Gebied opgeven op één van vier manieren: adres (+ straal_m, standaard 500 m), lat/lon (+ straal_m), wkt (POLYGON in WGS84, lon lat) of gemeente. Zonder gebied: heel België. totaal is het aantal dat aan de filters voldoet; waarnemingen is een steekproef (max 300). Gebruik per_jaar en per_dataset voor het beeld; zoek_url toont dezelfde zoekopdracht op gbif.org. Met dataset_key worden alleen records van één brondataset getoond: zo klik je door vanuit de uitsplitsing per soort van soorten_in_gebied (veld datasets) naar de onderliggende records. per_verificatiestatus telt het veld identificationVerificationStatus over de teruggegeven records; waarnemingen.be en Florabank vullen dat, eBird, iNaturalist en Pl@ntNet niet ('(leeg)'). Lees kanttekening en neem ze over in het advies.

Args: soort: Nederlandse of wetenschappelijke naam, of GBIF-taxonKey. adres: bv. 'Kortrijksesteenweg 100, Gent'. straal_m: straal in meter rond adres of lat/lon (standaard 500). wkt: bv. 'POLYGON((3.70 51.03,3.75 51.03,3.75 51.07,3.70 51.07,3.70 51.03))'. gemeente: naam van een Belgische gemeente (GADM). jaar_van: eerste jaar (inclusief). jaar_tot: laatste jaar (inclusief). max_resultaten: aantal individuele waarnemingen dat wordt teruggegeven (max 300 per oproep). offset: startpositie voor paginering (bv. 300 voor de tweede pagina). dataset_key: beperk tot één GBIF-brondataset (UUID uit per_dataset of uit het veld datasets). ook_niet_commercieel: ook datasets onder CC BY-NC (alleen niet-commercieel gebruik) meenemen. Standaard aan: de uitvoer is bedoeld als intern werkdocument. Zet op False wanneer het resultaat gedeeld of gepubliceerd wordt; dan komen alleen datasets onder CC0 en CC BY mee.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`lat`	No
`lon`	No
`wkt`	No
`adres`	No
`soort`	Yes
`offset`	No
`gemeente`	No
`jaar_tot`	No
`jaar_van`	No
`straal_m`	No
`dataset_key`	No
`max_resultaten`	No
`ook_niet_commercieel`	No

Output Schema

TableJSON Schema

Name	Required	Description
`soort`	No
`gebied`	Yes	Omschrijving van het gebruikte gebied (WKT, gemeente of adres+straal).
`offset`	No
`totaal`	Yes	Totaal aantal waarnemingen dat aan de filters voldoet (kan groter zijn dan wat is teruggegeven).
`periode`	No
`per_jaar`	No
`zoek_url`	Yes	Dezelfde zoekopdracht op gbif.org, ter controle.
`per_dataset`	No	Verdeling over datasets (naam, sleutel, aantal).
`kanttekening`	Yes	Verplichte lezing: beperkingen van de data.
`teruggegeven`	Yes
`waarnemingen`	Yes
`licentiefilter`	No
`waarschuwingen`	No
`geraadpleegd_op`	Yes
`per_verificatiestatus`	No	Telling van identificationVerificationStatus over de teruggegeven records; '(leeg)' = veld niet gevuld door de bron.
`records_met_broedindicatie`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.9.0Sep 18, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full disclosure burden and does so well: it reveals that waarnemingen is only a sample capped at 300 while totaal is the true count, explains pagination via offset, and warns that per_verificatiestatus counts only the returned records and that several sources don't fill identificationVerificationStatus ('(leeg)'). It also discloses the licensing default (output is an internal work document) and instructs the agent to read and carry over kanttekening into the advice. Minor gaps remain: no explicit read-only statement, rate limits, or error behavior.

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

Conciseness4/5

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

The description is front-loaded with a one-sentence purpose, then proceeds through area modes, output semantics, caveats, and a compact Args reference. It is long, but the length is justified for a 13-parameter tool with zero schema descriptions; the only real redundancy is that area modes are explained both in the prose and again per-parameter in Args.

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?

Given the tool's complexity (13 parameters, no annotations, 0% schema coverage), the description is remarkably complete: it covers filtering, area modes, pagination, sampling limits, data-quality caveats, licensing, and the sibling workflow. Since an output schema exists, the description rightly focuses on behavior and parameters rather than return-value fields; remaining gaps are minor (error conditions, no-result behavior, rate limits).

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

Parameters5/5

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

Schema description coverage is 0%, so the description must fully compensate, and it does: the Args block documents all 13 parameters with formats, examples, constraints, and defaults (e.g., soort accepts a Dutch/scientific name or GBIF taxonKey; wkt gives a POLYGON in WGS84 lon lat; max_resultaten caps at 300). It also conveys cross-parameter constraints the schema cannot express, such as the four alternative area-specification modes and that dataset_key takes a UUID from per_dataset or the datasets field.

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?

The opening sentence states a specific verb+resource: 'Waarnemingen van één soort in een gebied en periode (GBIF, België)' — observations of one species in an area and period from GBIF Belgium. This immediately distinguishes it from sibling tools like soorten_in_gebied (species list per area) and zoek_soort (name resolution). The description even explains the click-through relationship to soorten_in_gebied's datasets field, further reinforcing the differentiation.

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?

The description explains the four mutually exclusive area-specification modes (adres, lat/lon, wkt, gemeente) and the whole-Belgium default, telling the agent exactly how to form a query. It explicitly names a sibling workflow (dataset_key clicking through from soorten_in_gebied's datasets field) and gives license-usage guidance (set ook_niet_commercieel to False when sharing/publishing). However, it stops short of explicit 'use X instead of this tool' exclusions for the other siblings.

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

Deploy Server