This server provides access to the UK Environment Agency's Real Time Flood Monitoring API, enabling near real-time flood and water data retrieval with no API key required.
Flood Warnings & Alerts
Retrieve current flood warnings and alerts, filtering by location (lat/long/distance), county, or severity level (Severe, Warning, Alert, No longer in force)
Get full details for a specific warning by ID
Flood Areas
Browse flood alert and warning areas with geographic and pagination filters
Retrieve details for a specific flood area by its area code
Monitoring Stations
Discover stations measuring water levels, flows, temperature, wind, and more
Filter by location, town, river, catchment, station type (SingleLevel, Coastal, Groundwater, etc.), status, or parameter
Get comprehensive details for a specific station by ID
Measurement Types (Measures)
List available measurement types across all stations or for a specific station
Real-time & Historical Readings
Access readings updated every 15 minutes; filter by date, date range, latest only, parameter, or qualifier
Retrieve time-series data for a specific measure or all readings from a specific station
Supports pagination and sorting for large datasets
General Capabilities
Geographic filtering using latitude, longitude, and distance (km)
Pagination via limit and offset parameters
Context-window safe responses: capped at 500 items, polygons omitted, and truncated at ~60 KB
No API key or registration required — uses open government data freely
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., "@Environment Agency Flood Monitoring MCP Server show me current flood warnings in Yorkshire"
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.
A Model Context Protocol (MCP) server that provides access to the UK Environment Agency's Real Time Flood Monitoring API. This server allows you to access near real-time flood warnings, water level measurements, flow data, and monitoring station information.
Migrated to the modern MCP SDK (@modelcontextprotocol/sdk 1.x), added Zod input validation (range, format, and cross-field checks), 30s request timeouts with actionable errors, id sanitization, and response capping (polygon omission, default/max limits, and 60 KB truncation) to protect the client's context window.
Related MCP server: Zyfy MCP Server
🚨 Flood Warnings & Alerts: Get current flood warnings and alerts with severity levels
📍 Flood Areas: Access information about flood alert and warning areas
🏭 Monitoring Stations: Find water level and flow monitoring stations across the UK
📊 Real-time Measurements: Access water levels, flows, and other measurements updated every 15 minutes
📈 Historical Data: Retrieve historical readings and measurements
🗺️ Geographic Filtering: Filter data by location using latitude, longitude, and distance
🔓 No API Key Required: Uses open government data with no registration needed
Add this to your Claude Desktop configuration:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"environment-agency": {
"command": "npx",
"args": ["-y", "mcp-server-environment-agency"]
}
}
}npm install -g mcp-server-environment-agencyget_flood_warnings - Get current flood warnings and alerts
get_flood_warning - Get details of a specific flood warning
get_flood_areas - Get flood areas (regions where warnings may apply)
get_flood_area - Get details of a specific flood area
get_monitoring_stations - Get monitoring stations that measure water levels, flows, etc.
get_monitoring_station - Get detailed information about a specific monitoring station
get_measures - Get measurement types available across all stations
get_station_measures - Get all measurement types from a specific station
get_readings - Get measurement readings from all stations
get_measure_readings - Get readings for a specific measurement type
get_station_readings - Get all readings from a specific monitoring station
Get detailed information for station 1029TH (Bourton Dickler)
Find monitoring stations within 25km of Cambridge
Find monitoring stations in Yorkshire
Show me today's water level readings from any 5 stationsSevere Flood Warning - Severe Flooding, Danger to Life
Flood Warning - Flooding is Expected, Immediate Action Required
Flood Alert - Flooding is Possible, Be Prepared
Warning no Longer in Force - The warning is no longer in force
Water Level (level) - Water levels at monitoring stations
Flow (flow) - Water flow rates
Temperature (temperature) - Air temperature
Wind (wind) - Wind direction and speed
SingleLevel - Single water level measurement
MultiTraceLevel - Multiple level measurements
Coastal - Coastal monitoring stations
Groundwater - Groundwater level monitoring
Meteorological - Weather measurements
Node.js 20+
TypeScript
git clone https://github.com/dwain-barnes/mcp-server-environment-agency.git
cd mcp-server-environment-agency
npm installnpm run build# Build and run the end-to-end smoke test (spawns the server over stdio,
# lists tools, exercises a live query, and checks id sanitization)
npm test# Link for local testing
npm link
# Test with Claude Desktop using local versionThis server uses Environment Agency flood and river level data from the real-time data API (Beta), provided under the Open Government Licence.
Data is updated every 15 minutes
The API may redirect during high load - the client follows redirects automatically
Responses may be cached for short periods
No service level guarantee - not suitable for safety-critical applications
For tracking all measurements, use a single call every 15 minutes
Use geographic and parameter filters to reduce response sizes
The API has built-in limits: default 500 items, maximum 10,000 for readings
Use pagination with limit and offset parameters for large datasets
To keep responses friendly to LLM context windows, this server shapes and caps API results:
Default page size: 50 items for stations, measures and flood areas; 100 for readings (applied when you don't pass limit).
Maximum limit: 500 for any list tool. The Environment Agency API itself allows more, but this server caps for context safety — use offset to paginate.
Polygon geometry omitted: flood-area and flood-warning polygons are replaced with a short placeholder, as they are the single largest field in the API.
60 KB truncation: if a rendered response still exceeds ~60,000 characters, the items list is progressively truncated and a note explains how many items were omitted and which filters (county, river_name, town, or lat+long+dist) or pagination to use.
Responses use a compact { meta, count, items } envelope with the API @context field stripped.
This project is licensed under the MIT License - see the LICENSE file for details.
Environment Agency for providing open flood monitoring data
Model Context Protocol team for the excellent framework
UK Government for open data initiatives
Built by Dwain Barnes 🇬🇧
Get details of a specific flood area by area code
| Name | Required | Description | Default |
|---|---|---|---|
| area_code | Yes | Flood area code (e.g., '122WAC953') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get details'), implying it's non-destructive, but doesn't cover error handling, rate limits, authentication needs, or what 'details' include (e.g., format, depth). For a tool with no annotation coverage, this is a significant gap.
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 a single, efficient sentence with zero waste. It's front-loaded with the core purpose and uses clear, direct language, making it easy to parse quickly.
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 low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic operation but lacks behavioral details and usage context. Without annotations or output schema, it should do more to explain what 'details' include or error cases.
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 description adds minimal value beyond the input schema, which has 100% coverage. It mentions the parameter 'area_code' but doesn't provide additional context like valid code formats beyond the schema's example, or where to obtain codes. With high schema coverage, the baseline is 3.
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 verb 'Get' and the resource 'details of a specific flood area', specifying it operates 'by area code'. It distinguishes from sibling tools like 'get_flood_areas' (plural) by focusing on a single area, but doesn't explicitly contrast with other flood-related tools like 'get_flood_warning'.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when-not-to-use scenarios, or compare to sibling tools like 'get_flood_warning' or 'get_flood_areas', leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get flood areas (regions where warnings/alerts may apply)
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude for geographic filter (WGS84) | |
| long | No | Longitude for geographic filter (WGS84) | |
| dist | No | Distance in km for geographic filter | |
| limit | No | Maximum number of results (default 500) | |
| offset | No | Offset for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves flood areas but doesn't describe key behaviors: whether it's a read-only operation (implied by 'Get'), what the return format looks like (e.g., list of areas with properties), pagination details (though offset is in schema), rate limits, or authentication needs. For a tool with 5 parameters and no annotations, this is a significant gap.
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 a single, efficient sentence that front-loads the core purpose ('Get flood areas') and adds clarifying context in parentheses. There's no wasted verbiage or redundancy, making it easy to parse quickly.
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 complexity (5 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the return values (e.g., what properties flood areas include), how results are ordered, or error conditions. For a geographic query tool with pagination, more context is needed to use it effectively.
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?
Schema description coverage is 100%, with clear descriptions for all 5 parameters (lat, long, dist, limit, offset). The description adds no parameter-specific information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.
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 verb 'Get' and the resource 'flood areas', with additional context about what flood areas represent ('regions where warnings/alerts may apply'). This distinguishes it from siblings like 'get_flood_warnings' or 'get_measures' by focusing on geographic regions rather than warnings or measurements. However, it doesn't explicitly differentiate from 'get_flood_area' (singular), which might retrieve a specific area.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over siblings like 'get_flood_warnings' (which might provide actual warnings) or 'get_flood_area' (which might retrieve a single area by ID). There's no context about prerequisites, such as needing geographic coordinates for effective use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific flood warning by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Flood warning ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves details but doesn't describe what those details include, whether it's a read-only operation, error handling (e.g., for invalid IDs), or any rate limits. This leaves significant gaps for a tool with no annotation coverage.
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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates what the tool does, making it easy to parse and understand quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what details are returned, error conditions, or how this tool fits into the broader context of sibling tools (e.g., vs. 'get_flood_warnings'). For a tool with no structured support, more descriptive context is needed.
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 description coverage is 100%, with the parameter 'id' fully documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., format examples or ID sources), so it meets the baseline score of 3 for high schema coverage without extra value.
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 action ('Get details') and resource ('specific flood warning by ID'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its sibling 'get_flood_warnings' (plural), which appears to retrieve multiple warnings rather than a single one by ID.
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 provides no guidance on when to use this tool versus alternatives like 'get_flood_warnings' or other sibling tools. It mentions retrieving by ID but doesn't clarify prerequisites (e.g., needing an ID from another source) or exclusions (e.g., not for bulk retrieval).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current flood warnings and alerts. Updated every 15 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| min_severity | No | Minimum severity level (1=Severe Flood Warning, 2=Flood Warning, 3=Flood Alert, 4=No longer in force) | |
| county | No | Filter by county name (e.g., 'Somerset', 'Yorkshire') | |
| lat | No | Latitude for geographic filter (WGS84) | |
| long | No | Longitude for geographic filter (WGS84) | |
| dist | No | Distance in km for geographic filter (used with lat/long) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about update frequency ('Updated every 15 minutes'), which isn't in the schema, but doesn't cover other key behaviors like rate limits, authentication needs, error handling, or response format. For a read-only tool with no annotations, this leaves significant gaps in transparency.
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 two sentences with zero waste: the first states the core purpose, and the second adds critical behavioral context (update frequency). It's front-loaded with essential information and appropriately sized for the tool's complexity, making it highly efficient and easy to parse.
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 moderate complexity (5 parameters, no output schema, no annotations), the description is partially complete. It covers purpose and data freshness but lacks details on response structure, error cases, or usage trade-offs with siblings. Without annotations or output schema, more behavioral and contextual information would improve completeness for effective agent use.
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?
Schema description coverage is 100%, so the schema fully documents all 5 parameters with clear descriptions and an enum for 'min_severity'. The description adds no parameter-specific information beyond what the schema provides, such as default values or interaction rules. Baseline 3 is appropriate as the schema handles the heavy lifting.
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 specific action ('Get current flood warnings and alerts') and resource ('flood warnings and alerts'), distinguishing it from sibling tools like 'get_flood_area' or 'get_measure_readings' which target different resources. The addition of 'Updated every 15 minutes' further clarifies the data's freshness, making the purpose unambiguous.
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 implies usage for retrieving current flood data, but provides no explicit guidance on when to use this tool versus alternatives like 'get_flood_warning' (singular) or geographic filtering tools. It lacks statements about prerequisites, exclusions, or comparisons with siblings, leaving usage context partially inferred rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get readings for a specific measurement type
| Name | Required | Description | Default |
|---|---|---|---|
| measure_id | Yes | Measure ID (e.g., '1491TH-level-stage-i-15_min-mASD') | |
| latest | No | Get only the most recent reading | |
| today | No | Get all readings from today | |
| date | No | Get readings from specific date (YYYY-MM-DD) | |
| startdate | No | Start date for date range (YYYY-MM-DD) | |
| enddate | No | End date for date range (YYYY-MM-DD) | |
| since | No | Get readings since specific datetime (ISO format) | |
| view | No | Set to 'full' for detailed information | |
| sorted | No | Sort by date (descending) | |
| limit | No | Maximum number of results | |
| offset | No | Offset for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get readings') but doesn't cover critical traits like whether this is a read-only operation, potential rate limits, authentication needs, or what the output format looks like (e.g., list of readings with timestamps). This is a significant gap for a tool with 11 parameters and no output schema.
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 a single, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 complexity (11 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values, error conditions, or how parameters like 'latest', 'today', and date ranges interact. For a data retrieval tool with many filtering options, more context is needed to guide effective usage.
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?
Schema description coverage is 100%, so all parameters are documented in the input schema. The description adds no additional meaning beyond implying filtering by 'measurement type', which aligns with the 'measure_id' parameter. Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate with extra context like parameter interactions or default behaviors.
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 verb ('Get') and resource ('readings for a specific measurement type'), making the purpose understandable. It doesn't explicitly distinguish from sibling tools like 'get_readings' or 'get_station_readings', which might have overlapping functionality, so it lacks full sibling differentiation.
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?
No guidance is provided on when to use this tool versus alternatives like 'get_readings' or 'get_station_readings'. The description implies usage for a specific measurement type but doesn't specify exclusions or prerequisites, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get measurement types available across all stations
| Name | Required | Description | Default |
|---|---|---|---|
| parameter_name | No | Parameter name (e.g., 'Water Level', 'Flow') | |
| parameter | No | Short parameter name (e.g., 'level', 'flow') | |
| qualifier | No | Qualifier (e.g., 'Stage', 'Downstream Stage') | |
| station_reference | No | Station reference ID | |
| station | No | Station URI | |
| limit | No | Maximum number of results | |
| offset | No | Offset for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does ('Get measurement types') without mentioning permissions, rate limits, pagination behavior (despite offset/limit parameters), error conditions, or what the return format looks like. This is inadequate for a tool with 7 parameters.
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 a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information.
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?
For a tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'measurement types' means in this context, how results are structured, or provide any behavioral context. The agent would need to guess about important aspects of tool behavior.
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?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. Baseline 3 is appropriate when the schema does all the parameter documentation work.
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 verb ('Get') and resource ('measurement types'), and specifies scope ('available across all stations'). However, it doesn't explicitly differentiate from sibling tools like 'get_station_measures' or 'get_measure_readings', which appear related but have different scopes.
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 provides no guidance on when to use this tool versus alternatives like 'get_station_measures' or 'get_measure_readings'. It mentions 'across all stations' which implies a broad scope, but doesn't clarify use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific monitoring station
| Name | Required | Description | Default |
|---|---|---|---|
| station_id | Yes | Station ID (e.g., '1491TH') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves 'detailed information' but doesn't specify what that includes (e.g., station metadata, status, location), whether it's a read-only operation, potential errors (e.g., invalid station_id), or performance aspects. This leaves significant gaps in understanding the tool's behavior.
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 a single, clear sentence with zero wasted words. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration, making it highly efficient.
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 complexity of a data retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'detailed information' entails, how results are structured, or handle edge cases, leaving the agent with insufficient context to use the tool effectively beyond basic parameter input.
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 input schema has 100% description coverage, with 'station_id' documented as 'Station ID (e.g., '1491TH')'. The description adds no additional parameter semantics beyond this, so it meets the baseline of 3 where the schema does the heavy lifting without compensating for any gaps.
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 verb ('Get') and resource ('detailed information about a specific monitoring station'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_monitoring_stations' (plural) or 'get_station_readings', which might retrieve similar or related data.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'get_monitoring_stations' (likely for listing stations) and 'get_station_readings' (likely for readings data), there's no indication of context, prerequisites, or exclusions for selecting this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get monitoring stations that measure water levels, flows, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| parameter_name | No | Parameter name (e.g., 'Water Level', 'Flow', 'Temperature') | |
| parameter | No | Short parameter name (e.g., 'level', 'flow', 'temperature') | |
| qualifier | No | Qualifier (e.g., 'Stage', 'Downstream Stage', 'Groundwater', 'Tidal Level') | |
| town | No | Filter by town name | |
| catchment_name | No | Filter by catchment name | |
| river_name | No | Filter by river name | |
| search | No | Search text in station labels | |
| lat | No | Latitude for geographic filter (WGS84) | |
| long | No | Longitude for geographic filter (WGS84) | |
| dist | No | Distance in km for geographic filter | |
| type | No | Station type | |
| status | No | Station status | |
| view | No | Set to 'full' for detailed information including scale data | |
| limit | No | Maximum number of results | |
| offset | No | Offset for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states what the tool retrieves without disclosing behavioral traits like pagination behavior (implied by 'limit' and 'offset' parameters but not explained), rate limits, authentication needs, or whether it's a read-only operation. The description is minimal and lacks critical operational context.
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 a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and uses examples ('water levels, flows, etc.') to clarify scope without unnecessary elaboration.
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 complexity (15 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain the tool's behavior, output format, or how to interpret results (e.g., what 'full' view entails). For a tool with many filtering options and no structured output documentation, more context is needed to guide effective use.
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?
Schema description coverage is 100%, so the schema fully documents all 15 parameters. The description adds no parameter-specific information beyond the general mention of 'water levels, flows, etc.', which loosely relates to 'parameter_name' but doesn't enhance understanding. Baseline 3 is appropriate as the schema does the heavy lifting.
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 verb ('Get') and resource ('monitoring stations') with specific examples of what they measure ('water levels, flows, etc.'). However, it doesn't explicitly differentiate this tool from its siblings like 'get_monitoring_station' (singular) or 'get_station_measures', leaving some ambiguity about scope.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'get_monitoring_station' (likely for a single station) and 'get_station_measures' (likely for station-specific measurements), there's no indication of how this tool differs in context or filtering capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get measurement readings from all stations. Updated every 15 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| latest | No | Get only the most recent reading for each measure | |
| today | No | Get all readings from today | |
| date | No | Get readings from specific date (YYYY-MM-DD) | |
| startdate | No | Start date for date range (YYYY-MM-DD) | |
| enddate | No | End date for date range (YYYY-MM-DD) | |
| parameter | No | Filter by parameter (e.g., 'level', 'flow') | |
| qualifier | No | Filter by qualifier (e.g., 'Groundwater', 'Tidal Level') | |
| station_reference | No | Filter by station reference | |
| station | No | Filter by station URI | |
| view | No | Set to 'full' for detailed measure information | |
| sorted | No | Sort by date (descending) | |
| limit | No | Maximum number of results (default 500, max 10000) | |
| offset | No | Offset for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about data update frequency ('Updated every 15 minutes'), which helps set expectations. However, it doesn't describe response format, error handling, rate limits, or authentication requirements, leaving significant gaps for a tool with 13 parameters.
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 extremely concise with just two sentences that each earn their place. The first sentence states the core purpose, and the second provides important behavioral context about data freshness. No wasted words or redundant information.
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?
For a tool with 13 parameters and no output schema or annotations, the description is minimal but functional. It covers the basic purpose and data freshness, but doesn't address response format, error cases, or how to interpret the various filtering parameters. The schema provides good parameter documentation, but the description could do more given the tool's complexity.
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?
Schema description coverage is 100%, so all parameters are well-documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, but it does imply temporal filtering through 'Updated every 15 minutes,' which provides context for date-related parameters. Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose: 'Get measurement readings from all stations.' It specifies the resource (measurement readings) and scope (all stations), though it doesn't explicitly differentiate from sibling tools like 'get_measure_readings' or 'get_station_readings' which suggests similar functionality.
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 provides some implied usage context with 'Updated every 15 minutes,' indicating data freshness, but it doesn't explicitly state when to use this tool versus alternatives like 'get_measure_readings' or 'get_station_readings.' No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all measurement types available from a specific station
| Name | Required | Description | Default |
|---|---|---|---|
| station_id | Yes | Station ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but does not cover critical traits like whether this is a read-only operation, potential rate limits, authentication needs, or error handling. This leaves significant gaps in understanding the tool's behavior.
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 a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for its function, earning a high score for conciseness.
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 lack of annotations and output schema, the description is incomplete. It does not explain return values, error cases, or behavioral nuances, which are essential for a tool with no structured metadata. This leaves the agent with insufficient context for effective use.
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 description coverage is 100%, with the parameter 'station_id' fully documented in the schema. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage.
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 verb ('Get') and resource ('all measurement types available from a specific station'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'get_measures' or 'get_measure_readings', which might retrieve similar data, so it falls short of a perfect score.
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 provides no guidance on when to use this tool versus alternatives, such as 'get_measures' or 'get_measure_readings'. It lacks context about prerequisites, exclusions, or specific scenarios, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all readings from a specific monitoring station
| Name | Required | Description | Default |
|---|---|---|---|
| station_id | Yes | Station ID | |
| latest | No | Get only the most recent readings | |
| today | No | Get all readings from today | |
| date | No | Get readings from specific date (YYYY-MM-DD) | |
| startdate | No | Start date for date range (YYYY-MM-DD) | |
| enddate | No | End date for date range (YYYY-MM-DD) | |
| since | No | Get readings since specific datetime (ISO format) | |
| view | No | Set to 'full' for detailed information | |
| sorted | No | Sort by date (descending) | |
| limit | No | Maximum number of results | |
| offset | No | Offset for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but lacks critical behavioral details such as whether this is a read-only operation, potential rate limits, authentication requirements, error handling, or what the output format looks like (especially since there's no output schema).
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 a single, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 complexity (11 parameters, no annotations, no output schema), the description is insufficient. It doesn't address behavioral aspects, output expectations, or usage context, leaving significant gaps for an agent to understand how to invoke and interpret results effectively.
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 input schema has 100% description coverage, so the schema already documents all 11 parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain parameter interactions or default behaviors), meeting the baseline for high schema coverage.
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 verb ('Get') and resource ('all readings from a specific monitoring station'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_readings' or 'get_measure_readings', which appear to serve similar functions, so it lacks sibling distinction.
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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_readings' and 'get_measure_readings' available, there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_flood_areaget_flood_areasget_flood_warningget_flood_warningsget_measure_readingsget_measuresget_monitoring_stationget_monitoring_stationsget_readingsget_station_measuresget_station_readingsMost tools have distinct purposes targeting specific resources like flood areas, warnings, stations, or readings, with clear boundaries. However, some overlap exists between get_readings (all stations) and get_station_readings (specific station), which could cause minor confusion if not carefully read.
All tools follow a consistent verb_noun pattern with 'get_' prefix, using snake_case throughout. The naming is highly predictable and readable, making it easy for agents to understand the action and target resource.
With 11 tools, the count is well-scoped for a flood monitoring domain, covering key resources like areas, warnings, stations, and readings. Each tool appears to earn its place without feeling excessive or insufficient.
The toolset provides comprehensive read-only coverage for monitoring flood data, including areas, warnings, stations, and readings. A minor gap is the lack of tools for historical data queries or subscription/alert management, but core real-time monitoring workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Access UK flood warnings, river levels, water quality, Met Office forecasts, and carbon data
Access UK air quality data, monitoring sites, and hourly pollutant measurements across regions
Real-time water levels and flow rates from USGS stream gauges
Flood MCP — wraps Open-Meteo Flood API (free, no auth)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dwain-barnes/mcp-server-environment-agency'
If you have feedback or need assistance with the MCP directory API, please join our Discord server