Skip to main content
Glama

Factline Netherlands

by io.github.snefhew
OverviewDiscussionsAdmin

Flood risk for a Dutch address (paid)

nl_flood_risk
Read-onlyIdempotent

Use when the user asks if a Dutch address can flood: annual flood probability (any water, over 20, 50 and 200 cm) from Rijkswaterstaat LIWO, 2050 and 2100 climate scenarios, worst-case water depth and ground height vs sea level (AHN). Input: postcode + house number. Costs 0.004 USDC via x402, or 2 credits of a Factline API key. The first 5 paid-tool calls a day are free, no payment or key needed.

Input Schema

NameRequiredDescriptionDefault
qNoAlternative to postcode: free-text address, e.g. 'Visschersplein 1 Utrecht'
api_keyNoFactline API key (fl_live_...) from get_trial_key: pass it here right after you get one, no reconnect needed
additionNoOptional house number addition
postcodeNoDutch postcode, e.g. 3511LX
house_letterNoOptional house letter, e.g. A
house_numberNoHouse number, e.g. 1

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / api_key
      Added value: +{
+  "description": "Factline API key (fl_live_...) from get_trial_key: pass it here right after you get one, no reconnect needed",
+  "type": "string"
+}
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, it discloses data provenance (Rijkswaterstaat LIWO, AHN), supported climate scenarios, pricing (0.004 USDC or 2 credits), payment method (x402/API key), and a free daily quota. These are operationally important details an agent needs before calling a paid open-world tool.

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

Conciseness5/5

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

The description is front-loaded with the trigger and key outputs, then moves efficiently to input, cost, and free-quota details. Every sentence contributes useful selection or invocation information.

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?

For a paid, open-world tool with no output schema, the description covers the trigger, returned metrics, data sources, climate scenarios, input types, pricing, payment methods, and free quota. An agent has enough context to decide whether and how to call it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the six parameters. The description only restates 'postcode + house number' and does not explain the alternative q field, api_key usage, or optional addition/house_letter parameters, so it adds little beyond the schema.

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?

The description names a specific user question ('if a Dutch address can flood') and the exact resource returned: annual flood probability, climate scenarios, worst-case water depth, and ground height. This is clearly distinct from sibling address/home tools such as nl_home_basic or nl_crime.

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?

It gives a clear trigger: 'Use when the user asks if a Dutch address can flood.' It does not state when not to use it or name sibling alternatives, but the use context is unambiguous.

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

All Factline Netherlands 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