Belgium Data Desk

River, canal and tide levels in Flanders now (waterinfo.be)

river_levels

Read-only

Live water levels at about 650 river, canal and tidal gauges in Flanders and on the Flemish waterways (VMM and HIC, waterinfo.be): the nearest gauges to an address or point, a named gauge, or the gauges on a river. For each gauge: the level now in metres TAW (and above the gauge zero where that is how it is published), the change over 1, 3 and 24 hours (rising/falling/steady, or low and high water for tidal gauges), the 24-hour minimum and maximum, how far it is below the gauge's official watch and alarm levels, whether it is within its usual range (the long-term band of 80 % of the time), the publisher's official alarm status and its short-term forecast status. Starts with key_facts. Values are provisional measurements updated every 5-15 minutes. Does not say whether a specific address will flood (use flood_risk for Flanders' official flood-prone maps), and does not cover Wallonia (SPW's terms forbid passing its gauge data on), Brussels' Flowbru gauges, discharge or rainfall. Examples: How high is the Dijle at Korbeek-Dijle, and how far from the alarm level? → {"station":"Korbeek-Dijle"}; Is the Demer rising near Diest? → {"address":"Grote Markt 1, 3290 Diest","river":"Demer"}; Water levels around Ghent now → {"address":"Korenmarkt 1, 9000 Gent","radius_km":5}; The tide in the Scheldt at Antwerp → {"latitude":51.2213,"longitude":4.3977,"max_stations":2}.

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": "river_levels"
  }
}

Input Schema

Name	Required	Description
`river`	No	Only gauges on this river or canal, e.g. 'Demer', 'Zeeschelde', 'Dender', 'Kanaal Gent-Terneuzen'; combine with an address to get that stretch.
`address`	No	Address or place, e.g. 'Grote Markt 1, 3000 Leuven': the nearest gauges are returned.
`station`	No	A gauge by name or number instead of a place, e.g. 'Korbeek-Dijle', 'L08_097', 'Werchter', 'Antwerpen tij'.
`latitude`	No	WGS84 latitude, e.g. 51.0453 (use with longitude instead of address).
`longitude`	No	WGS84 longitude, e.g. 3.7275.
`radius_km`	No	Search radius around the place in km, default 10.
`x_lambert72`	No	Belgian Lambert 72 (EPSG:31370) x in metres, as an alternative to latitude/longitude.
`y_lambert72`	No	Belgian Lambert 72 (EPSG:31370) y in metres.
`max_stations`	No	How many gauges to return, default 3.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations only declare readOnly/openWorld/not-destructive, so the description carries the real burden and it does: values are provisional, refreshed every 5-15 minutes, and the response 'starts with key_facts'. It also discloses a legally motivated coverage gap (SPW forbids passing Walloon gauge data on), which annotations cannot express. Minor gap: no statement on pagination, error behaviour for unmatched stations, or what key_facts actually contains.

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?

Front-loads the core purpose, then per-gauge payload, then exclusions, then examples — a sensible ordering. The per-gauge field enumeration is dense but earns its place because there is no output schema to document return shape. Slight bloat: the long parenthetical descriptions of watch/alarm levels and usual-range bands could be tightened.

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?

With nine optional parameters, no required fields, no enums and no output schema, the description must supply both selection logic and return shape — and it does both, listing every returned measurement (level in metres TAW, 1/3/24h change, 24h min/max, alarm margins, usual-range band, alarm and forecast status). Coverage limits and the key_facts preamble close the remaining ambiguity.

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 100%, so the baseline is 3; the description earns a notch above by showing how parameters combine in practice ('combine with an address to get that stretch', river+address in the Demer example, lat/long with max_stations for tides). It does not add format-level detail the schema lacks (e.g. what a station number looks like beyond the schema's own example, or whether x_lambert72 alone is valid).

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?

Opens with a specific verb and resource: 'Live water levels at about 650 river, canal and tidal gauges in Flanders', names the publishers (VMM/HIC, waterinfo.be) and enumerates the three access modes (nearest gauges to a place, named gauge, gauges on a river). It also names the sibling it is not — 'use flood_risk for Flanders' official flood-prone maps' — so an agent can separate it from the flood tool without 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 Guidelines5/5

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

Gives explicit when-to-use cases via four worked examples keyed to parameter sets (station lookup, address+river, address+radius, lat/long), and explicit when-not-to-use exclusions: no flood prediction, no Wallonia (with the licensing reason), no Flowbru Brussels gauges, no discharge or rainfall. Alternatives are named rather than 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 tools Inspect

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.