Belgium Data Desk

Find boreholes, wells, CPTs, soil profiles or groundwater permits in Flanders

search_subsurface

Read-only

Find DOV records by area and attributes, e.g. the deepest boreholes in a municipality, geothermal boreholes since 2020, groundwater wells in the Brussel sand with quality data, electric CPTs near an address, soil profiles with lab data, or the largest groundwater abstraction permits in a municipality (with the licensed total per aquifer). Area: a municipality (official 2025 boundary; old pre-merger names work), or an address/coordinates with radius_m, or nothing for all of Flanders. Filtering and sorting run on DOV's server, so counts cover every matching record. Use get_subsurface_record with a result id for details. Examples: The deepest boreholes in Leuven → {"record_type":"boreholes","municipality":"Leuven","limit":3}; Geothermal boreholes drilled in Flanders since 2020 → {"record_type":"boreholes","purpose":"geothermal","date_from":"2020","limit":5}; The largest groundwater abstraction permits in Ghent → {"record_type":"groundwater_permits","municipality":"Gent","sort":"largest","limit":5}.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "record_type": "<record_type>"
    },
    "name": "search_subsurface"
  }
}

Input Schema

Name	Required	Description
`sort`	No	Default: nearest with a location; otherwise deepest (boreholes, CPTs), newest (wells), largest (permits), most_described (soil profiles).
`limit`	No	Results to list, default 10.
`address`	No	Address in Flanders, as an alternative to municipality (then radius_m applies).
`aquifer`	No	Wells and permits: HCOV code (A0620, or A06 for the whole system) or words from the unit name ('Brussel', 'Krijt').
`date_to`	No	Same formats as date_from.
`purpose`	No	Boreholes: why it was drilled.
`latitude`	No	WGS84 latitude, e.g. 51.0453 (use with longitude instead of address).
`radius_m`	No	Radius around the address or coordinates, default 1000 m.
`date_from`	No	YYYY, YYYY-MM or YYYY-MM-DD: drilling/test date, last water-level date for wells, permit start, survey date.
`longitude`	No	WGS84 longitude, e.g. 3.7275.
`cpt_method`	No	CPTs: electric CPTs also measure sleeve friction.
`max_depth_m`	No	Maximum depth, same fields.
`min_depth_m`	No	Minimum depth (borehole or CPT depth, well screen bottom, permitted well depth).
`record_type`	Yes	What to find.
`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.
`municipality`	No	Municipality in Flanders, e.g. 'Leuven' or 'Merelbeke-Melle'.
`min_annual_m3`	No	Permits: minimum licensed annual volume in m³.
`with_lab_data`	No	Soil profiles: only those with lab samples.
`with_quality_data`	No	Wells: only screens with groundwater quality samples.
`with_stratigraphy`	No	Boreholes: only those with a formal, hydrogeological or Quaternary stratigraphy.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, non-destructive, openWorld), but the description adds substantive behavior: filtering and sorting run server-side so counts cover every matching record, the 2025 official boundary is used while pre-merger names still resolve, and permits carry a licensed total per aquifer. It does not describe result ordering guarantees or pagination beyond the limit cap, keeping it short of a 5.

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?

Purpose and area scoping are front-loaded, with examples last, so the structure is sound. It is on the long side and the three JSON examples repeat information already implied by the schema, but each example disambiguates a real query shape rather than padding.

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?

For a 21-parameter tool with no output schema, the description covers area resolution, filtering, sorting defaults and the drill-down path well, and hints at the permit aggregation payload. It stops short of describing the returned record fields list or ordering of results, which would be the remaining gap.

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 already 100%, so the baseline is 3; the description goes further by showing cross-parameter intent, e.g. sort="largest" only makes sense for permits and municipality vs address/coordinates are alternatives. The examples demonstrate how record_type, purpose, date_from and sort combine 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?

Opens with a specific verb+resource ("Find DOV records by area and attributes") and enumerates the concrete record kinds it returns (boreholes, geothermal boreholes, wells, CPTs, soil profiles, permits). It is clearly separable from get_subsurface_record, which it names as the details follow-up.

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?

Explicitly states when to follow up elsewhere ("Use get_subsurface_record with a result id for details") and enumerates the valid area strategies: municipality, address/coordinates with radius_m, or nothing for all of Flanders. Worked examples map real questions onto parameter combinations, removing guesswork.

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.