Belgium Data Desk

Weather now, last days and 48-hour forecast in Belgium (KMI/IRM)

weather

Read-only

The weather at an address or point in Belgium from the Royal Meteorological Institute (KMI/IRM) open data: what the nearest synoptic station measures now (temperature, wind and gusts, humidity, cloud cover, pressure), its last 24 hours (minimum, maximum, precipitation), the last 7 days at the nearest automatic station (daily rain, max/min, sunshine), and KMI's ALARO model forecast for that point for the next 48 hours (3-hourly for the first day: temperature, precipitation, snow, wind, gusts, cloud cover) with 24-hour summaries and when rain is first expected. Starts with key_facts. Observations come from a station up to tens of km away; the forecast is a single deterministic model run without probabilities. Does not give official weather warnings (not in KMI's open data), climate normals, rain radar or forecasts beyond about 60 hours. Examples: What is the weather in Leuven now, and will it rain tomorrow? → {"address":"Grote Markt 1, 3000 Leuven"}; Weather forecast for Liège for the next two days → {"address":"Place Saint-Lambert 1, 4000 Liège"}; How windy is it at the coast in Ostend? → {"latitude":51.2194,"longitude":2.9269}.

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

Input Schema

Name	Required	Description
`address`	No	Address or place in Belgium, e.g. 'Grote Markt 1, 3000 Leuven' or 'Place Saint-Lambert 1, 4000 Liège'.
`latitude`	No	WGS84 latitude, e.g. 51.0453 (use with longitude instead of address).
`longitude`	No	WGS84 longitude, e.g. 3.7275.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnly/openWorld/non-destructive annotations: discloses that observations come from a synoptic station up to tens of km away, that the forecast is a single deterministic model run without probabilities, and that the response starts with key_facts. These are exactly the caveats needed to interpret results correctly.

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-loaded with purpose and richly information-dense, but delivered as one very long sentence chain that is harder to scan than bulleted time windows. Little actual waste — every clause (variables, caveats, exclusions, examples) carries decision-relevant content.

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?

No output schema exists, and the description compensates fully by specifying the return contents for each time horizon, the forecast granularity (3-hourly first day plus 24h summaries), rain onset timing, and the key_facts prefix. For a 5-parameter, single-purpose tool this leaves nothing critical unexplained.

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 adds value by tying example queries to which parameter form to use (address for named places, lat/long for Ostend coordinates) and by noting Lambert 72 is an alternative to lat/long. It does not specify precedence when both address and coordinates are supplied, so it stops short of 5.

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?

Specific verb+resource: retrieves current observations, last 24h/7d history, and a 48h ALARO forecast for a Belgian address or point, sourced from KMI/IRM open data. Enumerates the measured variables (temperature, wind/gusts, humidity, cloud cover, pressure, precipitation, sunshine), which clearly separates it from siblings like air_quality, flood_risk, and river_levels.

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?

Provides three worked natural-language-to-parameter examples (address vs latitude/longitude) so the agent knows the intended invocation patterns. Explicit when-not scope is given: no official weather warnings, no climate normals, no rain radar, no forecasts beyond ~60 hours — this steers the agent away from expecting those answers.

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.