Skip to main content
Glama
qinisolabs

floodwise

Official
by qinisolabs

floodwise

England flood-risk by postcode for AI agents — verified Environment Agency data, not guesses.

Verified, trustworthy data tools for AI agents. "Qiniso" means "truth" in Zulu.

Website · npm · MCP Registry


Ask an LLM "what's the flood risk at SW1A 1AA?" and it will answer confidently — but it cannot know: per-postcode flood risk is specific, curated data that lives in a government dataset, not in a model's weights. floodwise looks the postcode up in the Environment Agency's official "Flood risk: postcode search tool" data and returns the real long-term risk band — or an honest "not found" instead of a guess.

⚠️ Read this first — what floodwise is and isn't

  • England only. The data is the Environment Agency's, which covers England. Wales (Natural Resources Wales), Scotland (SEPA) and Northern Ireland (DfI) are not covered. A valid Welsh/Scottish postcode returns "not found", never a guess.

  • Area-level, not property-level. The risk is for the area around the addresses in a postcode — not a specific building. The EA states this data is "generally not suitable for property level assessment".

  • Long-term risk, not a live warning. It reflects the long-term annual chance of flooding, not whether flooding is happening now or forecast. It is not insurance, underwriting, surveying or professional advice.

Related MCP server: nor-data/nve-mcp

Add it to Claude

floodwise runs locally over stdio (no key, no login). Once it's on npm, add it under mcpServers in your client config:

{ "command": "npx", "args": ["-y", "floodwise"] }

Use it as a library

npm i floodwise
import { floodRiskByPostcode, validatePostcode } from "floodwise";

floodRiskByPostcode("SW1A 1AA");
// {
//   postcode: "SW1A 1AA", found: true, headlineRisk: "Very Low",
//   addressesAtRisk: { high: 0, medium: 0, low: 0 }, groundwater: "Unlikely",
//   coverage: "England", dataset: "ea-official", ...
// }

floodRiskByPostcode("EH1 1AA").found;   // false — valid postcode, but Scotland (out of EA coverage), no guess
validatePostcode("ec1a1bb");            // { valid: true, postcode: "EC1A 1BB", outcode: "EC1A", incode: "1BB" }

Postcodes are accepted spaced or unspaced, any case. A well-formed postcode that isn't in the loaded England dataset returns found: false with a clear note — it never invents a risk level.

Tools — 2

Tool

What it answers

flood_risk_by_postcode

The EA long-term flood-risk band (High/Medium/Low/Very Low) for an England postcode, address counts per band, and the groundwater indication

validate_postcode

Is this a well-formed UK postcode? (deterministic format check + outcode/incode split)

Data

The flood data is the Environment Agency "Flood risk: postcode search tool data" (England), published as open data under the Open Government Licence v3.0. Each postcode carries the number of addresses whose surrounding area is at high (≥3.3%/yr), medium (1–3.3%) or low (0.1–1%) long-term risk from rivers, sea or surface water (the highest of these), plus a separate groundwater Possible/Unlikely indication. Refreshed roughly quarterly.

This repository ships an illustrative starter sample (non-geographic ZZ pseudo-postcodes) so tests run out of the box — every response from it is tagged dataset: "sample". To load the real data, download Postcodes_Risk_Assessment_All.csv from data.gov.uk / the Defra Data Services Platform and run:

npm run build-data /path/to/Postcodes_Risk_Assessment_All.csv 2025-Q4
npm run build && npm test

Attribution: Contains public sector information licensed under the Open Government Licence v3.0. © Environment Agency copyright and/or database right. See NOTICE.

What it is not

  • Not advice. Not insurance, underwriting, surveying, mortgage or legal advice; not a property-level survey.

  • Not all flood types. Excludes flooding from highway drains, sewers and overland flow; groundwater is reported separately and isn't combined into the headline band.

  • Not the whole UK. England only (see above).

  • Not a guesser. Unknown/out-of-coverage postcodes return an honest "not found", never a fabricated risk level.

Architecture

A single TypeScript package exposing one MCP server over stdio (local / npx), driven by the same core.ts tool definitions that power the importable library. A Cloudflare Worker entry is included for a future hosted edge endpoint — note the full England dataset (~1.6M postcodes) exceeds the Worker bundle limit, so the hosted build will move the data into Cloudflare D1 (a follow-on); the npm library and stdio server run the full dataset directly.

npm install
npm run build
npm test

Privacy

This tool runs locally on your machine and is built not to collect, store, or transmit your data — no analytics, no telemetry, no account. All reference data is bundled — no network calls, and nothing leaves your device. Full policy: https://qinisolabs.github.io/privacy.html.

License

Apache-2.0. Flood data © Environment Agency, Open Government Licence v3.0; see NOTICE.

Available Tools

2 tools
flood_risk_by_postcodeA

USE THIS to get the Environment Agency's long-term flood-risk indication for an England postcode instead of guessing — e.g. when triaging a home/property insurance quote, underwriting, or answering 'is this address at flood risk?'. Returns the highest risk band (High/Medium/Low/Very Low) for the area around addresses in the postcode, the count of addresses in each band, and a separate groundwater indication. IMPORTANT: England only (not Wales/Scotland/NI), AREA-level not property-level, long-term risk not a live flood warning. Returns an honest 'not found' rather than inventing a risk level.

ParametersJSON Schema
NameRequiredDescriptionDefault
postcodeYesA UK postcode, e.g. 'SW1A 1AA' or 'sw1a1aa'.

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description fully carries the burden of transparency. It discloses the output (highest risk band, address counts per band, groundwater indication) and the honest 'not found' response. It also highlights limitations. It does not discuss authentication or rate limits, but for a simple query tool, this is adequate.

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 concise and well-structured, using a bold 'IMPORTANT' section for key constraints. Every sentence adds value, with no wasted words.

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?

Given the tool's simplicity (one parameter, no output schema), the description is complete enough. It explains the output structure, limitations, and error behavior. Lack of detailed output schema is acceptable because the description covers the key return fields.

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?

The schema covers the single parameter with example format, but the description adds the critical constraint that it is for England postcodes only, clarifying the geographic scope. This adds meaningful value 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 clearly states the tool retrieves the Environment Agency's long-term flood-risk indication for an England postcode. It specifies the verb 'get' and the resource, and distinguishes from the sibling 'validate_postcode' by describing its function as returning risk bands rather than validation.

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?

The description explicitly tells when to use the tool ('USE THIS to get ... instead of guessing') and provides concrete use cases (triaging insurance quotes, underwriting). It also states limitations (England only, area-level not property-level, long-term risk not live warning). However, it does not explicitly mention when not to use or alternatives beyond the sibling.

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

validate_postcodeA

USE THIS to check a UK postcode is well-formed and to split it into its outward and inward codes before storing or matching it — instead of trusting raw input. Deterministic format check only (no lookup); returns the canonical spaced form, outcode and incode.

ParametersJSON Schema
NameRequiredDescriptionDefault
postcodeYesThe UK postcode to validate.

TDQS

A4.5/5.0
Behavior4/5

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

Discloses deterministic format check only, no lookup, and return format. However, does not specify behavior on invalid input (error or response).

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?

Two concise sentences, imperative tone, no redundancy.

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?

Covers purpose, input, behavior, and return structure well for a single-parameter tool, but lacks details on invalid input handling.

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

Parameters5/5

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

Adds significant meaning beyond schema: UK postcode, well-formed, splitting, canonical spaced form. Schema just says 'UK postcode to validate'.

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?

Clearly states it validates a UK postcode and splits it into outward/inward codes, distinguishing it from the sibling tool which is about flood risk.

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?

Explicitly tells when to use ('before storing or matching') and what it doesn't do ('no lookup'), but lacks explicit alternatives or when not to use.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv0.1.0
    • First observedflood_risk_by_postcode
    • First observedvalidate_postcode

TDQS

A4.3/5.0
Disambiguation5/5

The two tools have clear, non-overlapping purposes: one retrieves flood risk data by postcode, the other validates postcode format. No ambiguity.

Naming Consistency5/5

Both tools follow a consistent verb_noun snake_case pattern: 'flood_risk_by_postcode' and 'validate_postcode'.

Tool Count3/5

With only 2 tools, the server feels thin for its domain. While the tools are well-defined, the scope is narrow and could benefit from additional flood-related operations.

Completeness2/5

The server covers only basic postcode validation and a single flood risk query. Missing features like live flood warnings, property-level risk, or historical data create significant gaps.

Maintenance

ActivityStale
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    MCP server that wraps NVE's open GIS data to provide flood risk and landslide risk point lookups, with explicit uncertainty reporting (e.g., 'no data' vs 'safe') and source references.
    2
    73
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    The deterministic fact-verification layer for AI agents. Validates the structured facts an agent emits — IBANs, payment cards, VAT and national tax IDs, crypto and bank addresses, domains, emails, phone numbers, securities and academic identifiers, plus dates, currencies and holidays — against checksums and curated authoritative data, not guesses.
    56
    1
    Apache 2.0
  • A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that gives AI assistants direct access to the FEMA National Flood Hazard Layer (NFHL) for flood zone lookups, FIRM panel information, and flood map data in the United States.
    15
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/qinisolabs/floodwise'

If you have feedback or need assistance with the MCP directory API, please join our Discord server