Belgium Data Desk

Soil, geology and groundwater at a place in Flanders

subsurface_at_location

Read-only

What is under a location in Flanders, read live from Databank Ondergrond Vlaanderen (DOV), the Flemish Government's subsurface database: the soil-map unit, the Tertiary and Quaternary geological map units and the groundwater bodies at the point, whether it lies in a drinking-water protection zone, the modelled column of geological and hydrogeological (aquifer) units with depths from DOV's 3D models (an answer even where no borehole exists), the boreholes, cone penetration tests (CPT) and groundwater monitoring wells within radius_m (counts plus the nearest and deepest, with ids), groundwater abstraction permits and described soil profiles within at least 1 km (licensed volume per aquifer; names of private persons withheld), and the current shallow groundwater status at the nearest status well. Starts with key_facts: the answer in a few sentences. Give an address in Flanders, or latitude/longitude, or Lambert 72 x/y. Use get_subsurface_record with a returned id for layer-by-layer borehole logs, CPT profiles or groundwater levels and quality. Map units and the model column are map- and model-scale information, not a site investigation. Examples: What is under the Grote Markt in Leuven? → {"address":"Grote Markt 1, 3000 Leuven"}; Deep aquifers and boreholes near Antwerp central station, for a geothermal question → {"latitude":51.2194,"longitude":4.4025,"radius_m":500,"max_depth_m":1000}.

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

Input Schema

Name	Required	Description
`address`	No	Address in Flanders, e.g. 'Grote Markt 1, 3000 Leuven'. Looked up in the Flemish address register.
`latitude`	No	WGS84 latitude, e.g. 51.0453 (use with longitude instead of address).
`radius_m`	No	Search radius for boreholes, CPTs and wells in metres, default 250.
`longitude`	No	WGS84 longitude, e.g. 3.7275.
`max_depth_m`	No	Deepest unit start listed in the modelled column, default 300 m; deeper units are counted. Raise it for deep geothermal or deep aquifer questions.
`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.6/5.0

Behavior4/5

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

Annotations already cover read-only, open-world, non-destructive, so the description earns credit for what it adds: live data source, response ordering with key_facts first, privacy handling (names of private persons withheld), scale limitation of map/model data, and that units deeper than max_depth_m are counted rather than listed. It stops short of describing pagination, error behavior for out-of-Flanders coordinates, or what happens when inputs conflict.

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 the core question and the data source, then structured as return contents, input options, alternative tool, caveat, and examples — a sensible order. The return-content enumeration is a single very long sentence that is dense to parse, though nearly every item listed is decision-relevant rather than filler.

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?

There is no output schema, so the description carries the full burden of describing the return, and it does so thoroughly: named sections, the key_facts summary, counts and nearest/deepest with ids, and the privacy and scale qualifications. Combined with concrete example payloads and the handoff to get_subsurface_record, an agent has everything needed to call it and interpret the result.

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 the schema already documents each parameter with defaults and examples, making 3 the baseline. The description adds genuine decision guidance beyond the schema — raise max_depth_m for deep geothermal or deep aquifer questions, radius_m governs the borehole/CPT/well search — and the example payloads show valid parameter combinations in practice.

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 concrete verb and resource — 'What is under a location in Flanders, read live from Databank Ondergrond Vlaanderen' — then enumerates precisely what is returned (soil-map unit, geological units, groundwater bodies, protection zones, modelled column, boreholes/CPTs/wells within radius, permits, shallow groundwater status). It explicitly contrasts itself with the sibling: 'Use get_subsurface_record with a returned id for layer-by-layer borehole logs'.

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 the three accepted location input styles (address in Flanders, latitude/longitude, Lambert 72 x/y), states the alternative tool and the condition that selects it, and supplies two worked example questions with their exact payloads. It also sets scope ('in Flanders') and a scale caveat ('not a site investigation'), so an agent can decide correctly without opening another tool.

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.