Skip to main content
Glama
Sign In

Belgium Data Desk

by io.github.vecture-be
OverviewDiscussionsAdmin

Flood-prone classes at a place in Flanders (official VMM maps)

flood_risk
Read-only

Whether an address or point in Flanders is flood-prone on the official VMM maps of flood-prone areas from rivers (fluvial), heavy rain (pluvial) and the sea, each as class A (no flooding modelled), B (small chance under climate change), C (small chance) or D (medium chance). These maps underlie the flood information required when property in Flanders is sold or let and the water test for permits. Includes the municipality (NIS code) with its population and income. Flanders only. Starts with key_facts; describes the location, not a building's floor level or defences. Examples: Is the Grote Markt in Leuven flood-prone? → {"address":"Grote Markt 1, 3000 Leuven"}; Flood classes at a point in Ghent → {"latitude":51.05,"longitude":3.72}.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "flood_risk"
  }
}

Input Schema

NameRequiredDescriptionDefault
addressNoAddress in Flanders, e.g. 'Groenplaats 1, 2000 Antwerpen'.
latitudeNoWGS84 latitude, e.g. 51.0453 (use with longitude instead of address).
longitudeNoWGS84 longitude, e.g. 3.7275.
x_lambert72NoBelgian Lambert 72 (EPSG:31370) x in metres, as an alternative to latitude/longitude.
y_lambert72NoBelgian Lambert 72 (EPSG:31370) y in metres.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine behavior beyond that: the data provenance (official VMM maps, the basis for property sale/let flood disclosure and the water test for permits), the four class meanings A-D, and the fact the response starts with key_facts. It omits failure behavior for unresolvable addresses or out-of-Flanders inputs.

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

Conciseness3/5

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

The core purpose is front-loaded, but the first sentence is a long run-on bundling sources, four class definitions and use cases, and the municipality population/income aside sits awkwardly in the middle. Most content earns its place, but the density makes it harder to scan than it needs to be.

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?

There is no output schema, so the description must explain return values, and it does: the A-D class semantics, the per-source breakdown, and the key_facts-first structure. For a read-only geo lookup with fully documented parameters, the remaining gap is edge-case behavior (ambiguous addresses, points outside Flanders), which is minor.

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 coverage is 100%, so baseline is 3; the description earns an extra point by showing two concrete question-to-parameters mappings (address string vs latitude/longitude pair), which clarifies which parameter combinations are valid in practice. It does not explain x_lambert72/y_lambert72 usage beyond what the schema already states.

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: determines whether an address or point in Flanders is flood-prone per the official VMM maps, broken down into fluvial, pluvial and sea sources with A-D classes. It also names the scope (Flanders only) and the secondary payload (municipality NIS code with population and income), so an agent can distinguish it from siblings like river_levels or weather without opening the 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?

Clear usage context is given: geographic restriction to Flanders, the explicit exclusion that it describes a location rather than a building's floor level or defences, and two worked examples contrasting the address path versus the coordinate path. It stops short of naming an alternative sibling (e.g. river_levels) for related questions, so routing between tools is left to inference.

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

All Belgium Data Desk toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources