Skip to main content
Glama

usgs-water-mcp-server

by io.github.cyanheads

Water Dataframe Query

water_dataframe_query
Read-onlyIdempotent

Run a read-only SQL SELECT against water data tables staged on a DataCanvas by water_get_series or water_find_sites. Workflow: run water_get_series or water_find_sites (get canvas_id + table_name) → water_dataframe_describe (confirm the table and its columns) → water_dataframe_query (SQL analysis). Only SELECT statements are permitted. At most 10,000 rows are returned; a query matching more is capped and the response sets truncated=true — scope with WHERE/LIMIT, and use SELECT COUNT(*) or water_dataframe_describe to learn the true match count. Requires DataCanvas to be enabled on this server instance. Returns an error if DataCanvas is not available.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYesRead-only SELECT statement. Reference the table by the table_name from water_get_series or water_find_sites; columns vary by source table, so run water_dataframe_describe first for the exact schema. Example: SELECT date_time, value FROM water_series_01646500_00060 ORDER BY date_time DESC LIMIT 10
canvas_idYesCanvas ID returned by water_get_series or water_find_sites. Identifies the canvas holding the data.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsNoResult rows returned (up to 10,000). Column names match the SELECT clause.
errorNoPresent when the call failed. Absent on success.
row_countNoNumber of rows returned in the rows array (up to the 10,000-row cap), not the total matched by the query. When truncated is true the cap was reached, so row_count equals the returned count and undercounts the true total. To get the true match count run SELECT COUNT(*) with the same filter, or call water_dataframe_describe for the full row count of the staged table; page large results with LIMIT/OFFSET.
truncatedNoTrue when the query matched more rows than the 10,000-row cap and the result was capped — rows and row_count then cover only the first 10,000 matches, and the rest are not in this response. False means rows and row_count are the complete result for this query. When true, narrow the query with WHERE, page with LIMIT/OFFSET, or run SELECT COUNT(*) with the same filter for the true total.

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's statement that only SELECT is permitted aligns with and reinforces these. The description adds valuable behavioral context beyond annotations: the 10,000-row cap with truncated=true response flag, the requirement for DataCanvas to be enabled, and the error condition when DataCanvas is unavailable. It doesn't detail the exact response structure, but the output schema exists, so that's covered. The only minor gap is not explicitly stating that the tool is non-destructive, but that's already in annotations.

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?

The description is a single paragraph that front-loads the core purpose (read-only SQL SELECT) and then provides workflow, constraints, and error conditions. It's dense but not bloated; every sentence adds necessary information. The only slight inefficiency is the repetition of the workflow steps, but that's acceptable for clarity. It could be slightly more structured with bullet points, but the current format is readable and efficient.

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?

Given the tool's complexity (SQL query execution with constraints), the description is complete: it covers prerequisites, workflow, allowed operations, result limits, error conditions, and how to handle large result sets. The output schema exists, so return values are documented. The description leaves no critical gaps for an agent to call this tool correctly.

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

Parameters4/5

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

Schema description coverage is 100%, so both parameters (sql and canvas_id) are well-documented in the schema. The description adds value by explaining the workflow context: canvas_id comes from water_get_series or water_find_sites, and sql should reference the table_name from those tools, with an example query. It also advises running water_dataframe_describe first for exact schema. This goes beyond the schema's basic descriptions, though the schema already covers the core semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs read-only SQL SELECT queries against water data tables staged on a DataCanvas, and explicitly names the prerequisite tools (water_get_series, water_find_sites) and the workflow step (water_dataframe_describe). This distinguishes it from siblings like water_get_readings and water_get_conditions, which are direct data retrieval tools, by emphasizing the SQL analysis capability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit workflow: run water_get_series or water_find_sites to get canvas_id and table_name, then water_dataframe_describe to confirm schema, then water_dataframe_query for SQL analysis. It also states when not to use it (only SELECT permitted) and how to handle large result sets (use WHERE/LIMIT, SELECT COUNT(*) or water_dataframe_describe for true counts). This is comprehensive guidance for an agent.

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

All usgs-water-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: site discovery, parameter lookup, instantaneous readings, time series, conditions, and dataframe analysis. No overlapping functionality.

Naming Consistency4/5

All tools start with 'water_' and mostly follow a verb_noun pattern (e.g., water_find_sites, water_get_readings). The dataframe tools (water_dataframe_describe, water_dataframe_query) use a noun_verb structure, which is a minor deviation.

Tool Count5/5

7 tools is well-scoped for the domain, covering essential operations without excess or deficiency.

Completeness4/5

The set covers key workflows: site discovery, parameter lookup, data retrieval (instantaneous, series, conditions), and analysis. Missing a dedicated tool for detailed site metadata, but find_sites provides reasonable coverage.

Resources