Skip to main content
Glama
jefseghers-del

gbif-mcp

by jefseghers-del
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

kaart_gebieden

Creates a situational map of a project location with surrounding protected areas on GRB base map, including legend and scale bar, for reports. Accepts address, coordinates, or polygon input for Flanders.

Instructions

Situeringskaart: de projectlocatie met de beschermde gebieden eromheen.

Tekent de gebieden uit gebieden_rond op de GRB-basiskaart van Digitaal Vlaanderen, in Lambert 72, met legende, schaalbalk, noordpijl en de zoekcirkel. Bedoeld als situeringsfiguur in een datarapport of nota. Alleen Vlaanderen.

Geeft het bestandspad terug plus de legende (per laag: kleur, aantal getekende vlakken, status). Een laag met status niet_geraadpleegd gaf een fout: daaruit volgt niet dat er geen gebied ligt. Lagen zonder vlak binnen de straal komen niet in de legende.

Args: pad: doelbestand; .png of .jpg. Voor een rapport met meerdere kaarten is .jpg aan te raden: de GRB-ondergrond is rasterbeeld, waardoor JPEG tot tienmaal kleiner uitvalt. adres: adres of plaatsnaam; of lat/lon (WGS84); of wkt (POLYGON in WGS84, lon lat). straal_m: zoekstraal én maat voor de kaartuitsnede (de kaart toont ±25 % meer). lagen: laag- of groepscodes zoals bij gebieden_rond; standaard natura2000, natuur en beheer. Voeg 'erfgoed' of 'bwk' toe voor beschermd erfgoed of de Biologische Waarderingskaart. breedte_px: beeldbreedte in pixels (600 tot 2400). met_legende: legende onder de kaart inbakken. Zet op False wanneer de kaart verkleind in een document komt: gebruik dan het veld legende uit de respons om ze in het document zelf op te maken, anders is de ingebakken tekst onleesbaar. per_groep: één kaart per thema in plaats van alles op elkaar. Aan te raden zodra de Biologische Waarderingskaart meedoet: die dekt het hele beeld en maakt de beschermingsgebieden onleesbaar. De bestandsnamen krijgen de groep als achtervoegsel (bv. situering-bwk.jpg) en de respons bevat dan een lijst kaarten.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNo
lonNo
padYes
wktNo
adresNo
lagenNonatura2000,natuur,beheer
straal_mNo
per_groepNo
breedte_pxNo
met_legendeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so strongly: it discloses the return value (file path plus legend with color, count, status), the meaning of `niet_geraadpleegd`, the fact that empty layers are omitted, the ±25% map-extent margin, and that `per_groep` returns a `kaarten` list. This goes well beyond what the schema tells the agent.

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?

The description is long but each sentence earns its place: purpose and output semantics are front-loaded, followed by per-parameter guidance and practical recommendations. There is no filler, and the structure mirrors the invocation workflow.

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

Completeness5/5

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

For a tool with 10 parameters, no annotations, and no output schema, this definition is exceptionally complete. It explains return fields, edge-case status values, file naming behavior, and when to change embedded options, giving the agent enough context to invoke it correctly in realistic report-generation scenarios.

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 compensate, and it does: every parameter is explained, including coordinate systems (WGS84 for adres/lat/lon/wkt, Lambert 72 for the map), file format constraints (.png/.jpg), pixel bounds (600-2400), and the dual role of `straal_m` as search radius and map cutoff. This fully compensates for the bare schema.

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 states a specific verb and resource: 'Tekent de gebieden uit `gebieden_rond` op de GRB-basiskaart van Digitaal Vlaanderen', producing a situational map with protected areas, legend, scale bar, north arrow, and search circle. It is clearly distinguished from data-returning siblings like `gebieden_rond` by framing itself as a situeringsfiguur for reports and notes.

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 explicitly gives intended use ('Bedoeld als situeringsfiguur in een datarapport of nota'), restricts use to Flanders, and gives concrete conditional recommendations: use .jpg for multi-map reports, disable the embedded legend for small reproductions, and use `per_groep` when the Biologische Waarderingskaart is included. It does not explicitly name exclusions among siblings, so it stops 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