GageLink is a read-only MCP server that gives AI agents hydrology data — river levels, streamflow, forecasts, basin info, and satellite water levels — with units, datums, timezones, and record quality kept attached.
Find monitoring stations by state, county, HUC, site type, or bounding box.
Describe a location to get metadata, including the vertical datum offset needed before comparing stage to surveyed elevations.
Get latest readings for parameters like discharge and gage height, with unit, datum, and provisional/approved status.
Fetch time series over a date range as a compact handle, then narrow it with slice_series.
Get annual peak flows for a station.
Get NOAA flood forecasts with flood thresholds, on the gage datum.
Get National Water Model forecasts for reaches, including ungaged ones.
Get SWOT satellite water surface elevations for river reaches, referenced to EGM2008.
Navigate the river network upstream or downstream along the main stem or tributaries.
Get drainage basin boundaries for a point.
Look up parameter codes to resolve what a reading measures.
Export a manifest to reproduce and audit every answer and quantity returned.
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., "@gagelink How high is the river at USGS-07374000 and what's the flood stage?"
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.
Hydrology data for AI agents, with the reference frames kept attached.
River levels, streamflow, flood forecasts, drainage basins and satellite water levels from USGS, NOAA, Hub'Eau, the UK Environment Agency and SWOT. Every value arrives carrying its unit, the datum it was measured from, its timezone, and whether the record is provisional or approved.
mcp-name: io.github.Adeniyikayodee/gagelink
Pre-alpha. The API may change.
pip install gagelink for the library. From an MCP client, with nothing installed:
{
"mcpServers": {
"gagelink": {
"command": "uvx",
"args": ["--from", "gagelink", "gagelink-mcp"]
}
}
}Or open the .mcpb bundle,
which carries the server and its dependencies in one file.
No account is needed. A free key raises the
allowance from 50 requests an hour to 1,000; set it as GAGELINK_API_KEY.
Related MCP server: Environment Agency Flood Monitoring MCP Server
How high is the river, and how does that compare with flood stage?
How much freeboard is there between the water and a surveyed levee crest?
What is the flow now, and what fraction of the record peak is that?
What is forecast over the next few days, and does it cross a flood category?
What lies upstream or downstream along the river network?
How large is the basin draining to this point?
What did a station record over a date range, and has that record been revised?
What is the water surface elevation of a river with no gage on it?
Is a reading provisional or approved, and how old is it?
At Little Falls on the Potomac, a river stage of 3.02 ft is measured upward from the
gage's own zero. A surveyed levee crest of 41 ft is measured upward from a national datum.
Both are lengths in feet, so subtracting one from the other produces a number that reads as
freeboard, and a units library will pass it.
The gage zero at this station sits 37.04 ft above NAVD88, so the stage is 40.06 ft on that datum and the freeboard is 0.94 ft. Subtracting without the offset gives 37.98 ft, which overstates the margin by a factor of 40 in the direction of calling a levee safe.
GageLink refuses that subtraction and returns the offset that makes it well defined. The same applies to satellite elevations, which sit on a geoid, and to modelled flows, which may have no measurement behind them.
python demo/freeboard.py runs the whole example offline from recorded responses.
The offset is available for most stations, so the refusal can become an answer. Pass
on_datum to describe_location and the station's offset is converted through NOAA's
VDatum, with the uncertainty of the conversion returned beside it:
altitude_of_gage_datum 4860 ft (NGVD29) Boulder Creek at mouth, CO
altitude_accuracy 10 ft, interpolated from a topographic map
altitude_on_requested_datum 4863.061 ft (NAVD88)
conversion_uncertainty 0.17 ft
offset_uncertainty 10 ftTwo things this surfaces are easy to miss.
The offset has an accuracy of its own. Across 7,361 USGS stream stations sampled in four
states, 3,397 publish an altitude for their gage datum. Of those, 72% are known no better
than a foot. The commonest published accuracy is 15 ft, a third were interpolated from a
topographic map, and about one in twenty is levelled to a hundredth. A freeboard is bounded
by that figure whatever precision the stage was read to, so describe_location returns it
alongside the method used to determine it.
Most stations are on the older datum. 58% of those altitudes are published on NGVD29 while a modern survey or lidar product is on NAVD88. Across the contiguous states the difference runs to feet.
on_datum also takes the tidal datums (MLLW, MLW, LMSL, MTL, DTL, MHW, MHHW)
for questions about level relative to the tide, and get_satellite_passes takes it to move
SWOT elevations off the EGM2008 geoid they are measured against. Both cover the contiguous
United States. Outside that coverage the conversion is refused and the reason is stated.
Tool | What it does |
| Find monitoring stations |
| Station metadata and reference frames |
| The latest reading for each parameter |
| A time series over a date range |
| Work with part of a retrieved series |
| Annual peak flows |
| Forecasts and flood thresholds |
| Modelled flow for ungaged reaches |
| Water levels measured from orbit |
| Upstream and downstream stations |
| The contributing drainage basin |
| Resolve a parameter code |
| Everything that answered the question |
All thirteen are read-only and annotated as such, so a client asks for consent once.
Results come back as structured data against each tool's output schema, so a unit, datum or grade is a field the client can read directly.
A series is returned as a handle with a summary. A year of 15-minute record is 35,000 values, and no answer needs them in a context window.
A tool list says what can be called. It does not say what to call first, and the datum rule above is an order of operations rather than a call. Four prompts state the ones that go wrong when a model assembles them itself.
Prompt | What it walks through |
| Fetch the offset, then difference, then bound the answer |
| Stage against flood category, now and over the forecast |
| The filter the relevant agency actually matches on |
| Answer, then export the manifest |
The tables that do not change between calls, readable without spending a request against the hourly allowance.
Resource | What is in it |
| The four rules that decide whether an answer is right |
| The common parameter codes and what each measures |
| Every datum named here, and which can be converted onto |
| Which tools answer for which country, and what each service omits |
| This conversation's ledger, without a tool call |
gagelink://parameter/{code} and gagelink://datum/{name} are templates, and their
variables complete: the server answers completion/complete for them and for the prompt
arguments with a closed set of values. The specification scopes completion to prompt
arguments and resource template variables, which is why those two vocabularies are exposed
as templates as well as inside the tool schemas.
Region | Services | Available |
United States | USGS, NOAA NWPS, NOAA National Water Model, NLDI, VDatum | All thirteen tools |
France | Hub'Eau | Search, metadata, latest readings, time series |
United Kingdom | Environment Agency | Search, metadata, latest readings |
Global | SWOT | Satellite water surface elevation |
ERA5, GRACE, CAMELS and HydroBASINS are available to library callers.
Each service publishes a different amount, and the tools say which. Hub'Eau states no unit on any value, so levels in millimetres and flows in litres per second are labelled here from a recorded table. The Environment Agency publishes no record grade on live data, so age is the only staleness signal for a UK reading.
To find a UK station, find_locations takes country=GB. The agency matches river and town
in full and in its own spelling, so River Thames returns stations and Thames returns
none. Free text matched against the station name is the filter to use when the agency's
spelling is unknown.
GageLink serves MCP revision 2026-07-28 and the three handshake revisions before it
(2025-06-18, 2025-03-26, 2024-11-05). It declares tools, prompts, resources and
completions, and declares listChanged false on all of them: every list is built at
import, so a client that subscribed would be waiting on a notification that cannot come.
The 2026 revision removed the initialize handshake. Every request carries its own version
and capabilities, so a client calls a tool on its first message and learns what the server
is through server/discover. Clients on the earlier revisions continue to open a session
and keep it.
Because a connection no longer implies a conversation, a client that wants a ledger of its
own names one in _meta:
{"_meta": {"io.github.adeniyikayodee.gagelink/conversation": "whatever-you-call-it"}}Each name gets its own manifest, quantities and checks. A client that sends no name shares the default.
For clients that cannot start a local process:
gagelink-mcp --http # http://127.0.0.1:8765/mcpThis binds to loopback and checks the Origin header. It has no authentication, so
--host on a reachable interface gives away your hourly allowance.
Every retrieval is recorded with its URL, the time it was made, and a hash of the response
body. export_manifest returns that record, and a session can be replayed later in three
modes:
offline uses the archived bodies
strict checks the live service returns identical data
revision_aware separates a changed answer caused by an official record revision from one
caused by changed code
The third mode exists because hydrology data is revised. A provisional measurement is often
approved or corrected months later, so an answer can change for reasons that have nothing to
do with the code. revision_aware tells the two causes apart.
Values are also checked against the ledger, so an answer can be audited:
[ok] 3.02 ft from get_latest.00065
[ok] 2960 ft3/s from get_latest.00060
[UNSOURCED] 116000 ft3/s no tool output produced this valuewaterbench measures whether the interface changes what a model gets right. It runs the
same nine tasks under three conditions: raw API responses, structured results with the
metadata stripped, and the full toolkit.
First results, gpt-oss-120b, eight replicates, 216 runs:
Condition | Correct |
Raw API | 61/72 |
Structured, no metadata | 63/72 |
GageLink | 70/72 |
Six of the nine tasks sit at ceiling, which is a finding about the suite. Where it separates, the causes are legible. Two long-record tasks sent 49,864 and 42,006 prompt tokens through raw JSON against 5,462 and 2,384 through the toolkit. On the opaque-unit task, stripping the reference frames sent seven of eight runs into the recorded trap, answering with the USGS discharge of 3010 ft³/s where the forecast service had published 2.95 kcfs.
One model and a small suite, so these numbers are an early signal about the interface. A general claim would need more models and more tasks.
python3 -m venv .venv
.venv/bin/pip install -e ".[dev]"
.venv/bin/pytestRequires Python 3.10 or later. The suite answers from recorded fixtures and needs no network
access. mypy src/gagelink is expected to be clean.
MIT
Metadata for one monitoring location: its name, position, drainage area, timezone, and the vertical datum its stage readings are measured from. Call this before comparing any stage against an elevation, because the answer depends on the offset it returns.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the returned offset is critical for comparisons, which is a useful behavioral note. However, it does not mention other aspects like whether the operation is read-only (though implied) or any error conditions. Given the context, a 3 is appropriate.
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, the first lists the output fields and the second gives a use case. No filler or repetition; every word adds value.
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 one parameter, no output schema, and no annotations, the description covers the core purpose and a key dependency (offset). It omits specifics about the identifier parameter, but overall it is reasonably complete for the tool's simplicity, earning a 4.
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 has one parameter 'identifier' with 0% coverage in the description. The description implies 'identifier' selects a location but does not explain its format, how to obtain it, or any constraints. Since the schema provides no detail, the description should compensate, but it does not go beyond a vague implication, warranting a score of 2.
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 it returns metadata for a monitoring location, enumerating the specific fields (name, position, drainage area, timezone, vertical datum). This distinguishes it from sibling tools like get_series or get_forecast, which focus on data retrieval rather than metadata. The verb 'describe' is implicit but well-understood.
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 advises calling this before comparing stage against elevation, providing a concrete use case. It does not mention when not to use it or alternatives, but the guidance is specific and actionable, earning a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The record of this session: every request made, every quantity returned, and the library versions. Enough to re-run the work and check the numbers. Call it last when the answer needs to be reproducible.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It details what is included (requests, results, library versions) and that it enables re-running, but it does not clarify whether the tool is read-only, destructive, or if any side effects occur. For a simple export, it could be more explicit about being safe to call.
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 sentences with clear, front-loaded purpose and a separate usage instruction. No filler. The second sentence could be tightened but is still compact.
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 simple tool with no parameters and no output schema, the description adequately explains its purpose and when to use it. It does not explain return format, but that's less critical since the tool is about creating a manifest and the description states what the manifest includes.
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 tool has zero parameters, so no parameter details are needed. The description's content is consistent with the schema, and the baseline for 0 params is 4. It implies expecting no arguments by not mentioning any.
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 identifies the tool as a manifest of the session (requests, quantities, library versions) and explains it enables re-running and checking numbers. This distinguishes it from the sibling data-access tools, which focus on specific data retrieval rather than session metadata.
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 states 'Call it last when the answer needs to be reproducible', giving precise guidance on when to use this tool (at the end, for reproducibility) and implicitly when not to use it. This is direct and actionable for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search USGS monitoring locations by state, county, hydrologic unit, site type, or bounding box. At least one filter is required. Returns identifiers of the form USGS-01646500, which every other tool takes.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | west,south,east,north in decimal degrees | |
| limit | No | ||
| state | No | Full state name, as in Maryland | |
| county | No | Full county name | |
| site_type | No | As in Stream, Lake, Well | |
| hydrologic_unit_code | No | HUC, any level |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals a key constraint ('At least one filter is required') and explains the output format ('Returns identifiers of the form USGS-01646500, which every other tool takes'). It does not mention the limit parameter or potential errors, but the key behaviors are disclosed.
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 long. The first sentence is front-loaded with the verb and resource, listing criteria. The second sentence highlights a key constraint and the output format. Every sentence earns its place with no redundancy or filler.
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 (6 parameters, no output schema, no annotations), the description is fairly complete. It specifies the search dimensions, the required-filter rule, and the form of returned identifiers. It does not describe the full response structure (e.g., whether additional metadata is returned), but for a search tool this is adequate.
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 provides descriptions for 5 of 6 parameters (83% coverage), so the baseline is 3. The description reinforces those same filters and adds the crucial constraint that at least one filter is required. However, it does not explain the 'limit' parameter beyond the schema's default, and it adds little semantic information beyond what the schema already contains.
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 function: 'Search USGS monitoring locations by state, county, hydrologic unit, site type, or bounding box.' This includes a specific verb and resource, and the variety of search criteria distinguishes it from sibling tools like describe_location or get_series.
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?
'At least one filter is required' provides a clear constraint for usage. The statement 'Returns identifiers of the form USGS-01646500, which every other tool takes' implies this is the entry point for other tools, giving context on when to use it. It does not explicitly list alternative tools for different search needs, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The area draining to a point. The area is computed from the delineated boundary rather than published; where a site record also states a drainage area, that figure is surveyed and is the one to quote.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It does reveal that the area is computed from a delineated boundary rather than published, and that in cases where a surveyed figure exists, that is the one to quote. This is useful nuance that helps the agent interpret results but does not cover other behaviors like output format or error cases.
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 only two sentences and 36 words, which is appropriately brief. However, the first sentence is more of a definition than a functional explanation, and the second sentence could be clearer. Still, no filler words are present.
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?
Despite having a single parameter and no output schema, the description is insufficient. It does not explain what 'identifier' refers to, what the returned data looks like, or how this ties into the hydrological domain. Sibling tools suggest a complex system, but this tool's description leaves out critical details an agent would need to invoke it correctly.
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 has one parameter 'identifier' with no description, and schema description coverage is 0%. The description does not mention the parameter at all, leaving the agent without any clue about what value to supply (e.g., a station ID? coordinates?). This is a critical gap that the description needed to address.
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 'The area draining to a point' defines a watershed but does not clearly state the tool's action (e.g., 'get' or 'retrieve'). It fails to specify that the tool returns the basin for a given identifier, leaving the purpose ambiguous. The second sentence adds detail about computation but not what the tool does.
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 given on when to use this tool versus siblings like get_latest or get_series. The description does not mention prerequisites, typical use cases, or alternatives. The only context is a note about 'where a site record also states a drainage area,' but it stops short of explaining when to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Observed and forecast stage from the NOAA National Water Prediction Service, with the flood thresholds that give them meaning. Stages and thresholds here are on the gage's own datum, so they can be differenced against each other and against a gage height, but not against a surveyed elevation without the offset from describe_location. Takes the USGS identifier or the NWS location id.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses a critical non-obvious behavior: stages are on the gage's own datum and cannot be compared to surveyed elevations without the describe_location offset. This is valuable context beyond what the schema or annotations provide, though it stops short of describing output structure or pagination.
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 three sentences with the core purpose first, followed by the datum caveat and identifier types. Every sentence adds necessary information without redundancy or filler.
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 single-parameter tool with no output schema, the description covers the data source, datum semantics, accepted identifiers, and relationship to describe_location. It could be slightly stronger by indicating whether the result is a time series or single current values, but overall it is sufficient for tool selection and basic 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 only specifies 'identifier' as required string with no description. The description adds meaning by explaining it accepts either a USGS identifier or an NWS location id, which is essential for correct invocation. It doesn't provide format examples or constraints, but the clarification is significant.
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 that the tool returns 'Observed and forecast stage from the NOAA National Water Prediction Service, with the flood thresholds that give them meaning.' This specific verb and resource, plus the mention of thresholds, distinguishes it from siblings like get_model_forecast or get_latest.
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 when to use the tool (when you need stage data on the gage's own datum) and references describe_location for surveyed elevation offsets, but it does not explicitly contrast this tool with get_model_forecast or other alternatives. No clear 'use this instead of X' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The most recent value the service holds for each parameter at a location. Latest is not the same as current: the service returns the last value it has for each parameter independently, so one response can carry a discharge from this morning beside a turbidity from years ago. Pass max_age_hours to drop the stale ones. Values arrive with their unit, datum, and whether the record is provisional or approved.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | ||
| parameters | No | Parameter codes, as in 00060 for discharge | |
| max_age_hours | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels: it reveals that the response is per-parameter independent snapshots, warns about the non-uniform timestamp issue with a concrete example, discloses that values include unit, datum, and provisional/approved status, and explains the effect of max_age_hours. This is far beyond what the schema alone indicates.
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?
Four sentences, each earning its place: the first states the core function, the second disambiguates the trickiest semantic trap, the third tells the agent how to control behavior, and the fourth describes the output envelope. The most critical caveat is front-loaded, and there is zero 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?
For a relatively simple three-parameter tool with no output schema or annotations, the description covers the key behavior dimensions: what values mean, how freshness is handled, and what extra fields come back. It could be more complete on what 'location' and 'identifier' mean and what happens if a parameter is not found, but those are minor for the described use case.
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 coverage is only 33% (only 'parameters' has a schema description), so the description must compensate. It meaningfully clarifies max_age_hours ('drop the stale ones') and implies 'identifier' maps to a location, but it never elaborates on the 'identifier' parameter format or what codes 'parameters' takes beyond a passing example in the schema. It's adequate but leaves the two most important parameters under-specified in prose.
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?
Uses a specific verb ('returns'), names the resource ('the most recent value the service holds for each parameter at a location'), and immediately distinguishes itself from a sibling concept ('Latest is not the same as current'), which clearly differentiates it from tools like get_series or get_model_forecast. The opening sentence alone fully answers what the tool does and scopes it to location/parameter.
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?
Provides clear context on when to use the tool (when the latest per-parameter values are needed, not an aligned current-time view) and hints at when to use alternatives by warning that values can be non-contemporaneous ('a discharge from this morning beside a turbidity from years ago'). It names the 'max_age_hours' mechanism for handling staleness, which directs the agent toward appropriate invocation. However, it doesn't explicitly name an alternative sibling tool or give an explicit 'don't use if...' condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
National Water Model streamflow for the reach a monitoring location sits on. These are modelled values, not measurements: the model covers reaches with no gauge on them, so a figure here may have nothing observed behind it, and it carries no record-quality grade. Series are analysis_assimilation, which looks back, and short_range, medium_range, medium_range_blend, and long_range, which look forward. Not every reach publishes every series.
| Name | Required | Description | Default |
|---|---|---|---|
| series | No | short_range | |
| identifier | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses that data is modelled, may lack actual observations, carries no record-quality grade, explains the temporal direction of each series, and notes inconsistent availability. This is transparent and goes well beyond minimal requirements.
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?
Three concise sentences front-load the purpose, then provide essential caveats and series information. Every sentence adds value; no fluff or repetition. The structure is logical 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 complexity (2 simple parameters, no output schema), the description is remarkably complete: it covers data provenance, quality limitations, series types, and availability variability. It does not explain return format, but without an output schema, the description still gives enough for an agent to understand expected data. The rich context makes it self-sufficient.
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 coverage is 0%, so the description must compensate. It explains the series parameter values with their look-back/forward nature, which adds meaning beyond the enum list. The identifier is implicitly linked to 'monitoring location', but no format or retrieval details are given. This partial compensation merits a 4.
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 National Water Model streamflow for a reach associated with a monitoring location. It emphasizes these are modelled values, contrasting with measurements, and lists the specific series types. This distinguishes it from generic forecast tools, though it does not explicitly name siblings.
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?
It clearly indicates when to use the tool (for modelled streamflow forecast data) and provides important caveats ('modelled values, not measurements', 'not every reach publishes every series'). However, it does not explicitly name alternative sibling tools or provide direct 'when not to use' guidance, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Annual peak flow record for a location, largest first. A water year can carry more than one peak, so the count of peaks is not the count of years.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| identifier | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It adds behavioral insight by noting that a water year can have multiple peaks and that records are sorted largest first, which prevents misinterpretation. However, it does not disclose whether the operation is read-only, any side effects, or data freshness, leaving gaps.
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 concise sentences, front-loaded with the main purpose and a key clarifying note. Every word adds value, with no filler or 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?
With no output schema and no annotations, the description must explain core behavior. It conveys the record type and sorting but omits details on output format, pagination, or parameter constraints. For a simple tool with two parameters, this is adequate but not rich enough to be fully complete.
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 coverage is 0%, so the description must explain parameters. It implies 'identifier' is a location but gives no detail on 'limit' or its default value (10). The description only hints at the required parameter, leaving the optional limit under-specified, which is insufficient for an agent to use the tool effectively.
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 returns an annual peak flow record for a location, sorted largest first. It distinguishes itself from sibling tools like get_series (time series) and get_latest (latest value) by specifying the peak flow nature and ordering, 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 peak flow data but does not explicitly state when to use this tool over alternatives such as get_latest or get_series. No exclusions or comparisons are provided, so the guidance is implicit rather than clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Water surface elevation measured from orbit by the SWOT mission, for a river reach. Covers reaches no gauge stands on. Elevations are referenced to the EGM2008 geoid, not to a national datum and not to any gage datum, so they cannot be differenced against a stage or a surveyed elevation. A reach identifier is a SWORD river reach id and is not a USGS station number.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ISO date | |
| start | Yes | ISO date | |
| feature_id | Yes | SWORD reach id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With NO annotations provided, the description carries full behavioral burden and exceeds expectations. It discloses the datum reference ('referenced to the EGM2008 geoid, not to a national datum and not to any gage datum'), issues a critical warning against misuse ('cannot be differenced against a stage or a surveyed elevation'), and clarifies identifier semantics ('SWORD river reach id and is not a US station number'). This prevents a whole class of subtle analysis errors.
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?
Three dense sentences, each earning its place: definition, coverage scope, and two critical caveats. No fluff or filler; every clause carries semantic weight. Could be marginally tightened but is well within the 'appropriately sized and front-loaded' bar.
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 only 3 simple parameters, no output schema, and no annotations, the description is remarkably complete. It covers purpose, coverage scope, datum references, cross-referencing caveats, and identifier format—addressing the highest-risk failure modes an agent could encounter when invoking this tool. Nothing material is left unexplained.
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 coverage is 100%, establishing a baseline of 3. The description adds genuine value by elaborating on feature_id ('is a SWORD river reach id and is not a US station number'), preventing an easy mix-up. The start/end parameters are self-explanatory ISO date strings, so the datum caveat—not parameter elaboration—is where the description's energy is best spent.
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 uses a specific resource ('Water surface elevation measured from orbit by the SWOT mission, for a river reach') and differentiates from sibling gauge-based tools by noting 'Covers reaches no gauge stands on.' This clearly distinguishes it from the gauge-data siblings like get_series and get_latest, making the purpose unmistakable.
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?
'Covers reaches no gauge stands on' gives explicit situational context for when to choose this tool over alternatives (i.e., when the reach is ungauged). It doesn't name sibling tools explicitly like the calibration HIGH example, but the implication is strong and unambiguous in context of available siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A date range of record, returned as a handle with a summary and a small sample rather than as its points, since a year of 15-minute record is 35,000 values. Use slice_series on the handle to narrow it. Resolution is daily or continuous.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| start | Yes | ISO date, as in 2026-08-01 | |
| parameter | Yes | ||
| identifier | Yes | ||
| resolution | No | daily |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It reveals the behavior of returning a handle with a summary and sample, and mentions the 'resolution' option, which is helpful. However, it does not explain what happens with invalid identifiers or whether the handle expires, or any side effects. It also doesn't specify how the sample is selected or the exact format of the summary, leaving some behavioral gaps.
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, well-structured sentence that front-loads the core purpose, explains the handle behavior, gives a concrete example of data size, and points to a sibling tool. Every clause earns its place with no fluff, making it efficient and easy to scan.
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), the description does a decent job of explaining the return type (handle) and the reason for it. However, it lacks details on error handling, pagination or limit of the sample, and how to use the handle with slice_series (e.g., passing it as an argument). Also, no mention of what happens if resolution is not specified, though the schema provides a default. These gaps are minor but could affect a smooth agent interaction.
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 only 20% (only start is described as ISO date), so the description must compensate. It adds meaning by explaining the 'resolution' parameter (daily or continuous) though not explicitly in the text, and the phrase 'a date range of record' implies start/end usage. It explains the high-level purpose of each parameter indirectly: identifier, parameter, start, end are standard, but it doesn't detail formats for identifier and parameter. The mention of 'resolution' via the tool's function is sparse, but the overall context helps.
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 a date range of records, but returns a handle with a summary and sample rather than raw points. It distinguishes itself from siblings like slice_series and get_peaks by noting the handle usage, though it could be more explicit about the resource (series) and the verb (get). It is specific enough to understand the core purpose, but lacks a clear contrast with get_series versus other retrieval tools.
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?
It gives a clear when-to-use hint: use this for large date ranges to avoid overwhelming data, and explicitly mentions using slice_series on the handle to narrow it, which guides the agent toward the next step. However, it does not explicitly state when NOT to use it (e.g., for small ranges) or mention alternatives like get_latest for recent data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a parameter code to what it measures, or find a code by name. Readings carry a code and no name, so this is how 00065 becomes gage height.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it can resolve in two directions (code to name, name to code) but does not mention any limitations, such as partial matches, case sensitivity, or whether it returns multiple results. There is no mention of output format or error 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 two sentences long, front-loaded with the primary action, and includes a concrete example. Every word contributes value; no fluff or 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?
The tool is simple (one parameter, no enums, no output schema). The description covers the essential purpose and usage. However, it lacks details about the return type (e.g., list of matches, a single name) and any edge cases. Given the simplicity and lack of annotations, it is minimally complete but could be richer.
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 0%, so the description must explain the 'query' parameter. It does: 'Resolve a parameter code to what it measures, or find a code by name' implies that 'query' accepts either a code or a name. This adds meaning beyond the schema, but it lacks specifics like format (e.g., '00065' vs 'gage height') or case sensitivity. Given one parameter and some elaboration, a 3 is adequate.
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 function: to resolve a parameter code to its measurement name or find a code by name. It uses a concrete example (00065 becomes gage height) and distinguishes it from other tools by focusing on parameter codes, not locations or series.
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 explains when to use this tool: when you have a parameter code that lacks a name. It implies that other tools may return codes without names, but it does not explicitly contrast with sibling tools or state when not to use it. Still, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Narrow a series already fetched under a handle and summarise what remains. Costs no request against the hourly allowance.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| handle | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses an important behavioral fact: 'Costs no request against the hourly allowance.' It also indicates local handling by mentioning 'already fetched under a handle,' but it remains vague about whether it mutates the stored series and what shape the summary takes.
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 short sentences communicate purpose, precondition, and quota behavior with no filler. The first sentence front-loads the core verb and resource, and the second adds a concise behavioral guarantee.
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?
The tool is simple with three parameters and no output schema, but the description still leaves ambiguity around the slice window (start/end) and the exact nature of the summary. It is adequate for basic orientation but not fully self-sufficient for invocation.
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 0%, so the description must compensate for start, end, and handle. It only explains that the series was retrieved under a handle, which gives some semantic weight to 'handle,' but says nothing about start/end roles, formats, or whether they are required. This is insufficient for a three-parameter tool.
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 a specific operation: narrow an already-fetched series under a handle and summarize what remains. The phrase 'already fetched under a handle' distinguishes it from sibling tools like get_series, which fetch new 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 precondition is clear: use it on a series already fetched under a handle rather than to fetch new data. The sentence 'Costs no request against the hourly allowance' gives a concrete reason for choosing it over network-fetching tools. It does not explicitly name alternatives, but the context is strong.
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.
v0.1.0describe_locationexport_manifestfind_locationsget_basinget_forecastget_latestget_model_forecastget_peaksget_satellite_passesget_serieslookup_parameternavigate_networkslice_seriesScored across 13 tools
Most tools have clearly distinct resource/action boundaries, and the descriptions are specific. The main confusable pair is get_forecast and get_model_forecast, both involving forecasts, though their sources and outputs differ. At most one or two tools could cause a misselection here.
All names follow a consistent verb_noun snake_case pattern. get_* is used for retrieval-style operations, and describe_, find_, slice_, navigate_, lookup_, and export_ clearly mark other action types. The overlap in name between get_forecast and get_model_forecast is a semantic concern, not a naming-pattern violation.
Thirteen tools is a well-scoped size for a water-data domain. Each tool covers a distinct part of the workflow—searching, metadata, observations, series, peaks, forecasts, satellite data, network traversal, basin geometry, parameter lookup, and export——so no tool feels redundant or missing from the count perspective.
The set covers the main observational lifecycle well: discover locations, describe metadata, get latest values, get and slice time series, get peaks, get forecasts, navigate upstream/downstream, and resolve parameter codes. The main gap is that get_satellite_passes requires a SWORD reach identifier, but the toolkit has no way to discover or translate a USGS location into that identifier, leaving that tool somewhat isolated.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Real-time water levels and flow rates from USGS stream gauges
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
River levels & flood alerts: USGS gauges. $0.01/query. Register in-session — free testnet funds.