gbif-mcp

telling_in_gebied

Count protected, red-list, and invasive species in a specified area. Get totals per category and dataset to support environmental assessments and permits.

Instructions

Hoeveel beschermde, Rode-Lijst- en invasieve soorten zijn in een gebied gemeld — alleen aantallen, snel.

Zelfde gebiedsparameters als soorten_in_gebied. Geeft per lijstcode en per categorie het aantal soorten, het aantal kernsoorten (bijlage IV Vl., bijlage II, VRL bijlage I, RL RE/CR/EN/VU), het aantal soorten met status dat tegelijk exoot is, en de totalen. Gebruik daarna soorten_in_gebied (bv. met filter='kern') voor de namen.

per_dataset toont de brondatasets met hun aantal records (komt gratis uit dezelfde facetbevraging). Het aantal soorten met status per dataset vergt één extra GBIF-oproep per dataset en staat daarom achter soorten_per_dataset=True (tien parallelle oproepen voor de tien grootste datasets, in de praktijk ±2 s extra); standaard uit, zodat de tool snel blijft.

Args: filter: lijst-/groepscodes (zie bronnen); standaard 'beschermd,rodelijst,invasief'. soorten_per_dataset: vul ook aantal_soorten_met_status per dataset in (trager, zie hierboven). 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	Default
`lat`	No
`lon`	No
`wkt`	No
`adres`	No
`filter`	No	beschermd,rodelijst,invasief
`gemeente`	No
`jaar_tot`	No
`jaar_van`	No
`straal_m`	No
`soorten_per_dataset`	No
`ook_niet_commercieel`	No

Output Schema

TableJSON Schema

Name	Required	Description
`kern`	Yes	Soorten met kernstatus (bijlage IV Vl., bijlage II, VRL bijlage I, Rode Lijst RE/CR/EN/VU).
`exoten`	Yes	Soorten met status die tegelijk als uitheems geregistreerd zijn.
`gebied`	Yes
`periode`	No
`zoek_url`	Yes
`licenties`	No	Records per licentie in het gebied, vóór de filter.
`per_lijst`	Yes	Aantal soorten per lijstcode.
`per_dataset`	No	Brondatasets in het gebied: dataset_key, dataset, aantal_records, en (alleen met soorten_per_dataset=True) aantal_soorten_met_status.
`kanttekening`	Yes
`lijstversies`	No
`per_categorie`	Yes	Per lijstcode: categorie -> aantal soorten.
`licentiefilter`	No	Welke datalicenties zijn meegenomen; standaard alleen CC0 en CC BY.
`totaal_soorten`	Yes
`waarschuwingen`	No
`geraadpleegd_op`	Yes
`rodelijst_dekking`	No
`totaal_waarnemingen`	Yes
`totaal_soorten_met_status`	Yes	Soorten met minstens één vermelding op de geraadpleegde lijsten.
`uitgesloten_niet_commercieel`	No	Records onder CC BY-NC die door de filter zijn weggelaten.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.9.0Sep 18, 2026

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses performance behavior: `soorten_per_dataset=True` triggers ten parallel GBIF calls and adds ~2 seconds, and is off by default to keep the tool fast. It also discloses licensing behavior: `ook_niet_commercieel` defaults to True because output is an internal working document, and must be set to False for sharing/publishing. It also notes that `per_dataset` counts come 'gratis uit dezelfde facetbevraging'. These are meaningful behavioral traits beyond the schema. It doesn't mention error cases or rate limits, but the disclosed behaviors are substantial.

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 well-structured: a one-sentence summary, a short paragraph on the relationship to `soorten_in_gebied`, a paragraph on `per_dataset` and `soorten_per_dataset`, and a bulleted Args list. It is longer than the typical description, but every sentence earns its place by explaining behavior or usage. The front-loaded summary is excellent. It loses one point for being somewhat dense and for the Args section partially repeating parameter names that are already in the schema, but the added context justifies most of the length.

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?

The tool has 11 parameters, no annotations, and an output schema. The description covers the tool-specific parameters and the key behavioral trade-offs (speed, licensing). It also tells the agent what to do next (`soorten_in_gebied` for names). It doesn't explain the area parameters, but those are likely shared with `soorten_in_gebied` and are named clearly in the schema. Given the complexity and the lack of annotations, the description is quite complete. A 5 would require explicit coverage of the area parameters or a pointer to where they are documented; a 4 is appropriate.

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

Parameters4/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 compensate. It explains `filter` (list codes, default 'beschermd,rodelijst,invasief'), `soorten_per_dataset` (adds per-dataset counts, slower), and `ook_niet_commercieel` (license filtering, default True, set False for sharing). It also references `per_dataset` as a concept. However, the area parameters (lat, lon, wkt, adres, gemeente, straal_m, jaar_van, jaar_tot) are not explained in the description, though they are likely shared with `soorten_in_gebied` and the schema names are fairly self-explanatory. The description adds real meaning for the three tool-specific parameters, which is the most important part.

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 description opens with a clear, specific question: 'Hoeveel beschermde, Rode-Lijst- en invasieve soorten zijn in een gebied gemeld — alleen aantallen, snel.' This states the verb (count/report), resource (protected, Red List, invasive species in an area), and the key constraint (counts only, fast). It also explicitly distinguishes itself from the sibling `soorten_in_gebied` by saying it returns counts and that `soorten_in_gebied` should be used for names. This is a strong purpose statement that differentiates it from siblings.

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

Usage Guidelines5/5

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

The description explicitly says 'Gebruik daarna `soorten_in_gebied` (bv. met filter='kern') voor de namen.' This tells the agent when to use this tool versus the sibling. It also explains when to set `ook_niet_commercieel` to False (when sharing/publishing) and when to enable `soorten_per_dataset` (when per-dataset counts are needed, with a cost/benefit note). This is explicit when/when-not guidance with alternatives.

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

Deploy Server