floodwise
OfficialThe floodwise server provides two tools for working with England flood-risk data and UK postcode validation:
flood_risk_by_postcode: Returns the Environment Agency's long-term flood-risk band (High / Medium / Low / Very Low) for a given England postcode, including the count of addresses in each risk band and a groundwater flooding indication (Possible / Unlikely). Returns "not found" for postcodes outside EA coverage (e.g. Wales, Scotland, Northern Ireland) rather than inventing a risk level. Data reflects long-term area-level risk, not live warnings.validate_postcode: Performs a deterministic format check on any UK postcode (no data lookup required), returning whether it is well-formed, its canonical spaced form, and the split into outward code (outcode) and inward code (incode).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@floodwisewhat's the flood risk for SW1A 1AA?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 floodwiseimport { 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
ZZpseudo-postcodes) so tests run out of the box — every response from it is taggeddataset: "sample". To load the real data, downloadPostcodes_Risk_Assessment_All.csvfrom 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 testPrivacy
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 toolsflood_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.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | A UK postcode, e.g. 'SW1A 1AA' or 'sw1a1aa'. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | The UK postcode to validate. |
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
v0.1.0- First observed
flood_risk_by_postcode - First observed
validate_postcode
TDQS
The two tools have clear, non-overlapping purposes: one retrieves flood risk data by postcode, the other validates postcode format. No ambiguity.
Both tools follow a consistent verb_noun snake_case pattern: 'flood_risk_by_postcode' and 'validate_postcode'.
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.
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
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
Postcodes MCP — wraps postcodes.io UK postcode API (free, no auth)
Canonical British Columbia Property Intelligence & Risk Screening MCP Server.
Unofficial MCP server for the public PortlandMaps property/permit/zoning API. Not city-affiliated.
Related MCP Servers
- AlicenseAqualityBmaintenanceMCP server for GOV.UK — search, content retrieval, organisation lookup, and postcode resolution.73MIT
- AlicenseAqualityDmaintenanceMCP 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.273MIT

Qinisoofficial
AlicenseAqualityBmaintenanceThe 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.561Apache 2.0- AlicenseNot gradedqualityDmaintenanceAn 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.15MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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