Skip to main content
Glama

UK Data: England river and tide levels

river_level_record

Read-onlyIdempotent

Record high, record low and highest recent level at one Environment Agency gauge, with how far today's level is below the record. Answers "is this a record flood" for journalists, residents and property buyers. Source: Environment Agency real-time flood-monitoring API (station stage scale). Records only cover the years the gauge has operated, and some gauges publish none. (cost: 1 credit)

Input Schema

NameRequiredDescriptionDefault
station_idNostring, required, Environment Agency station reference, e.g. 1491TH (Kings Mill, Oxford)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent and open-world, and the description adds genuinely new behavior: the EA flood-monitoring API source, the station-stage scale, limited year coverage and that some gauges publish no records at all, plus a credit cost. Return shape granularity (units, null handling) is the only thing left implicit.

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?

Front-loads the return values first, then the use case, then the source and caveats, then cost — a sensible order. The audience list is slightly promotional but doubles as usage guidance, so little is wasted.

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 one-parameter read tool with annotations and no output schema, every decision an agent needs is present: what it returns, what the data covers, when it may come back empty, and the credit cost.

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 coverage is 100% and there is a single parameter with an example, so the schema carries the semantics. The description only implies the single-gauge scoping ("one Environment Agency gauge") and adds nothing about how station_id maps to coverage gaps.

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?

States a specific verb and resource: record high, record low and highest recent level at one EA gauge, plus the derived delta from the record. This is clearly distinguishable from level-now and level-history siblings even though none are named explicitly.

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?

Frames the decision context well ("is this a record flood" for journalists, residents, property buyers), which tells an agent when this is the right tool. It stops short of naming alternatives such as river_level_now or river_level_history or stating exclusions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources