Hydrologiedaten für KI-Agenten. Flusspegel, Abfluss, Hochwasservorhersagen, Wasserqualität, Einzugsgebiete und Satelliten-Wasseroberflächenhöhen von USGS, NOAA und SWOT. Jeder Wert trägt seine Einheit, das Bezugssystem, von dem aus er gemessen wird, seine Zeitzone und ob der Datensatz vorläufig oder genehmigt ist.
mcp-name: io.github.Adeniyikayodee/gagelink
Vor-Alpha. Die API wird sich ändern.
{
"mcpServers": {
"gagelink": {
"command": "uvx",
"args": ["--from", "gagelink", "gagelink-mcp"]
}
}
}Für den Start ist kein Konto erforderlich. Ein kostenloser Schlüssel von api.waterdata.usgs.gov/signup erhöht das Kontingent von 50 Anfragen pro Stunde auf 1.000; setzen Sie ihn als GAGELINK_API_KEY.
Oder als Bibliothek:
pip install gagelinkRelated MCP server: mcp-usgs-water-data
Wie hoch ist der Fluss an einem Pegel, und wie verhält sich das zur Hochwasserstufe?
Wie viel Freibord besteht zwischen dem Wasser und einer vermessenen Deichkrone?
Wie hoch ist der Abfluss jetzt, und welcher Anteil des Rekordhöchstwertes ist das?
Was wird für die nächsten Tage vorhergesagt, und überschreitet es eine Hochwasserkategorie?
Was liegt flussaufwärts oder flussabwärts von diesem Punkt entlang des Flusses?
Wie groß ist das Einzugsgebiet, das zu diesem Punkt entwässert?
Was hat diese Station über einen Zeitraum aufgezeichnet, und wurde dieser Datensatz seitdem überarbeitet?
Wie hoch ist die Wasseroberfläche eines Flusses ohne Pegel?
Ist eine Messung vorläufig oder genehmigt, und wie alt ist sie?
Eine Pegelhöhe wird vom eigenen Bezugssystem der Station gemessen, nicht vom Meeresspiegel. Wenn man eine vermessene Höhe davon subtrahiert, erhält man eine Zahl, die wie ein Freibord aussieht und um dutzende Fuß falsch ist – in der Richtung, die einen Deich als sicher ausweist. Beide Werte sind Längen in Fuß, also trennt sie dimensional nichts, und keine Einheitenbibliothek fängt das ab.
Dieses Paket lehnt diese Subtraktion ab, statt sie zu beantworten, und describe_location gibt den Offset zurück, der sie wohldefiniert macht. Dasselbe gilt für Satellitenhöhen, die auf einem Geoid liegen, und für modellierte Abflüsse, hinter denen möglicherweise keine Messung steht.
Wasserdienste veröffentlichen bereits alles, was nötig ist, um ihre Daten korrekt zu verwenden. Ein Abfluss gibt seine Einheit an, ein Pegelstand gibt das Bezugssystem an, von dem aus gemessen wird, eine Messung gibt an, ob sie vorläufig oder genehmigt ist, und ein Zeitstempel gibt seinen Offset an. Clients parsen typischerweise die Zahl und verwerfen den Rest, und die Fehler folgen daraus.
Das Versagen ist messbar. In einem Benchmark von 4.288 Läufen über elf Modelle stellte quantity-guard fest, dass jedes Modell, das das Rechenwerkzeug erreichte, einen in Kubikfuß pro Sekunde veröffentlichten Abfluss in einen Parameter einspeiste, der in Kubikmetern pro Sekunde deklariert war, ohne umzurechnen – bei fast jedem Lauf, was eine Antwort ergab, die 35,3-mal zu groß war, ohne dass etwas in der Ausgabe darauf hindeutete. Sieben von elf Modellen differenzierten einen Pegelstand auf einem lokalen Pegel-Bezugssystem gegen eine Höhe auf NAVD88 und meldeten das Ergebnis als Freibord.
gagelink ruft die Daten mit den Metadaten ab und verwendet quantity-guard, um sie durchzusetzen, wenn die Werkzeuge des Agenten aufgerufen werden.
from gagelink import Service
service = Service(api_key="...") # free key, see below
page, retrieval = service.items(
"latest-continuous",
monitoring_location_id="USGS-07374000",
parameter_code="00060",
)
retrieval.record() # what a replay needs: url, params, time, status, sha256
retrieval.quota # Quota(limit=1000, remaining=999)items gibt die geparste Seite und den Datensatz des Abrufs zusammen zurück, nicht nur die Seite, weil eine Zahl, die eine Antwort erreicht, ohne die Anfrage, die sie erzeugt hat, nicht reproduzierbar ist, und die Kopplung am einzigen Einstiegspunkt billiger ist, als sich zu merken, sie aufzuzeichnen.
Nutzlasten werden zu Größen, die ihre eigenen Bezugssysteme tragen:
from gagelink import location_from, readings_from
page, _ = service.items("monitoring-locations", id="USGS-06730500")
station = location_from(page["features"][0])
station.register() # its datum, and the offset where one is published
observations, _ = service.items("latest-continuous", monitoring_location_id=station.id)
readings = {r.parameter_code: r for r in readings_from(observations, station)}
readings["00060"].value # Q(1.35 ft³/s (provisional))
readings["00065"].value # Q(9.11 ft (GAGE:06730500, provisional))
readings["00065"].value.to_datum("NGVD29") # Q(4869.11 ft (NGVD29, provisional))
readings["00065"].value.to_datum("NAVD88") # DatumConversionUnavailableDiese letzte Zeile ist der Punkt. Boulder Creek veröffentlicht seine Höhe auf NGVD29, also löst sich ein Pegelstand dort auf NGVD29 auf und lehnt NAVD88 ab, da der Offset zwischen beiden je nach Ort variiert und hier nicht veröffentlicht wird. Das moderne Bezugssystem anzunehmen, weil es das moderne ist, ist ein Freibordfehler einen Schritt früher als der, nach dem jeder sucht.
altitude und drainage_area kommen als nackte Zahlen zurück, und das Sammelschema gibt für keine von beiden eine Einheit an, also werden die USGS-Konventionen von Fuß und Quadratmeilen in normalise.py angewendet, wo sie sichtbar sind, statt weiter unten stillschweigend angenommen zu werden.
Eine Einheit ohne Zuordnung wird abgelehnt statt geraten. Eine Einheit, die pint parsen kann, für die dieses Paket aber keinen Eintrag hat, wird mit einer Warnung durchgelassen, weil parsebar nicht dasselbe ist wie verstanden: ppt liest pint als Teile pro Billion und bedeutet bei USGS Teile pro Tausend, was ein Faktor von 10^9 zwischen zwei dimensional identischen Messwerten ist.
Ein fehlender Wert ist hier null statt der -999999, die WaterServices veröffentlicht hat, und er bleibt fehlend. Der Qualifizierer sagt warum, ["EQUIP"] für einen Geräteausfall.
Die Genehmigung kommt als Provisional oder Approved statt als P oder A, und Zustandscodes stufen unterhalb ihres Prüfstatus ein, also wird ein genehmigter Datensatz einer eisbeeinflussten Messung als unverifiziert statt als genehmigt eingestuft.
Die Zeitzone der Station wird aus der Abkürzung zusammen mit dem Sommerzeit-Flag aufgelöst, da MST ohne Sommerzeit Arizona ist und MST mit Sommerzeit Colorado, und sie unterscheiden sich acht Monate im Jahr um eine Stunde.
Eine Sitzung hält den Zustand für eine Frage und den Datensatz dessen, was sie beantwortet hat. Werkzeuge geben ein Ergebnis zurück, statt eine Ausnahme zu werfen, weil ein Fehler mit einer Reparatur ein Modell im Gespräch hält, wo es sich selbst korrigieren kann, und eine geworfene Ausnahme die Runde beendet.
from gagelink import Session, Toolkit
with Session(question="How high is the Potomac at Little Falls?") as work:
kit = Toolkit(work)
kit.describe_location("USGS-01646500")
kit.get_latest("USGS-01646500", parameters=["00060", "00065"], max_age_hours=6)
work.audit("The gage height is 3.02 ft and the discharge is 2960 ft3/s.")
work.manifest()Jeder Wert verlässt das System mit seinem Bezugssystem, und jeder wird in einem Hauptbuch erfasst, sodass eine Antwort gegen das tatsächlich Abgerufene geprüft werden kann:
[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 valueDie dritte Zeile ist die Prüfung, die ihren Platz verdient. Die Zahl ist ein plausibler Abfluss für diesen Fluss, sie ist falsch, und nichts an dem Satz, der sie enthält, deutet darauf hin.
Eine Reihe wird als Handle mit einer Zusammenfassung und einer Stichprobe von zwanzig Punkten zurückgegeben statt als ihre Punkte, da ein Jahr mit 15-Minuten-Aufzeichnung 35.000 Werte umfasst. Das Handle wird aus der Abfrage abgeleitet, die es erzeugt hat, sodass eine Wiederholung derselben Sitzung dasselbe Handle erzeugt. Ergebnisse sind budgetiert, und alles, was verworfen wird, um innerhalb des Budgets zu bleiben, wird im Ergebnis angegeben, da eine stille Kürzung wie Abdeckung aussieht.
Werkzeug | Zweck |
| Suche nach Bundesstaat, County, hydrologischer Einheit, Standorttyp oder Begrenzungsrahmen |
| Metadaten, Bezugssystem, Zeitzone und der Offset, den ein Pegelstand benötigt |
| neuester Wert pro Parameter, mit Alter und Qualität |
| ein Datumsbereich, als Handle plus Zusammenfassung |
| eine gespeicherte Reihe eingrenzen, ohne erneut abzurufen |
| jährlicher Spitzenabfluss-Datensatz |
| beobachteter und vorhergesagter Pegelstand, mit Hochwasserschwellen |
| Überwachungsstandorte flussaufwärts oder flussabwärts entlang des Flusses |
| das Gebiet, das zu einem Punkt entwässert |
| einen Parametercode auflösen, da Messwerte keinen Namen tragen |
export GAGELINK_API_KEY=... # free, see below
gagelink-mcp{"mcpServers": {"gagelink": {"command": "gagelink-mcp"}}}Elf Werkzeuge, nicht mehr. Ein Modell verschlechtert sich, wenn seine Werkzeugliste wächst, also ist die Oberfläche nach Verben organisiert, und die Wahl, welcher Dienst antwortet, trifft der Server, statt dem Aufrufer überlassen zu werden.
Die Werkzeugbeschreibungen sind Teil des Produkts, nicht dessen Dokumentation. In der quantity-guard-Evaluierung stellte sich heraus, dass die Deklaration physikalischer Metadaten im Schema ohne Durchsetzung immer noch ein Drittel der Läufe rettete, die in der Basislinie scheiterten, also wirkt das, was eine Beschreibung über Bezugssysteme, Einheiten und vorläufige Datensätze sagt, bevor irgendeine Validierung läuft.
Ein Werkzeugfehler kommt als Inhalt zurück, der als Fehler markiert ist, statt als Protokollfehler, was die Reparatur vor dem Modell hält, statt die Runde zu beenden. Die Sitzung wird bei initialize zurückgesetzt, sodass die Größen einer Unterhaltung nicht im Manifest einer anderen auftauchen können.
python demo/freeboard.py führt das Ganze offline aus aufgezeichneten Antworten aus:
stage 3.02 ft (GAGE:01646500)
crest 41 ft (NAVD88)
The two are both lengths, so nothing dimensional separates them:
refused: cannot difference an elevation on NAVD88 against one on GAGE:01646500
The gage's zero is at 37.04 ft NAVD88, so the stage is 40.06 ft (NAVD88).
freeboard = 0.94 ft
Ignoring the datum gives 37.98 ft of margin where 0.94 ft is correct,
overstating it by a factor of 40.Ein Pegelstand und eine vermessene Höhe sind beide Längen in Fuß, und die Subtraktion des einen vom anderen ergibt eine Zahl, die wie ein Freibord aussieht. Der Fehler ist still, er läuft in die Richtung, einen Deich als sicher zu melden, und keine Einheitenbibliothek verhindert ihn, weil nichts an den Einheiten falsch ist.
Hochwasserschwellen stammen vom NOAA National Water Prediction Service, da ein Pegelstand nichts bedeutet, bis er gegen den Stand gesetzt wird, bei dem der Fluss über die Ufer tritt. Drei Dinge in dieser Nutzlast müssen behandelt werden, und keines ist ausgeschildert:
Der Abfluss erscheint als cfs in den Hochwasserkategorien und als kcfs im Statusblock derselben Antwort, also ist ein Aufrufer, der beide liest und sie gleich behandelt, um einen Faktor von tausend daneben.
Schwellen, die nie gesetzt wurden, werden als -9999 veröffentlicht statt weggelassen. Das ist dimensional gültig, nur im Vorzeichen plausibel und besteht jede nachgelagerte Prüfung, also wird es als das Sentinel gelesen, das es ist.
Pegelstände liegen auf dem eigenen Bezugssystem des Pegels, nicht auf einem nationalen. Der dort veröffentlichte beobachtete Pegelstand stimmt exakt mit USGS-Parameter 00065 an derselben Station und zur selben Zeit überein, was der Beleg für diese Lesart ist, und es ist der Grund, warum eine Hochwasserstufe gegen eine Pegelhöhe differenziert wird, aber nicht gegen eine vermessene Höhe.
Die Navigation verläuft entlang des Flusses statt innerhalb eines Radius, was die Unterscheidung ist, die die Antwort nützlich macht: Ein Pegel zwei Meilen entfernt im nächsten Einzugsgebiet ist hier flussaufwärts von nichts. Richtungen sind Wörter statt der zweibuchstabigen Codes des Index, also umfasst upstream Nebenflüsse und upstream_main folgt allein dem Hauptstrang.
Ein Einzugsgebiet kommt als Polygon von ein paar tausend Koordinatenpaaren. Das ist die Antwort auf eine Kartierungsfrage und die falsche Antwort auf jede Frage, die ein Agent stellt, also wird das Polygon behalten und seine Fläche, Ausdehnung und Scheitelpunktzahl werden gemeldet. Die Fläche wird aus dem Polygon durch die Linienintegralform der sphärischen Fläche berechnet, die keine Projektion benötigt und daher keine Zone hat, die zu wählen oder falsch zu wählen wäre. Sie stimmt mit dem Einzugsgebiet, das USGS für die eine Station veröffentlicht, an der beide Zahlen existieren, auf 0,06 % überein, und das Ergebnis sagt, dass es berechnet statt veröffentlicht ist, also wird es nicht gegen eine vermessene Zahl zitiert, als wären beide dasselbe.
Hydrologie reproduziert in der getesteten Literatur zu 1,6 %. Die übliche Erklärung ist, dass Daten und Code nicht veröffentlicht wurden, und sie verbirgt das interessantere Versagen: Eine veröffentlichte Pipeline gegen einen Live-Dienst reproduziert ebenfalls nicht, weil der Dienst den Datensatz darunter überarbeitet hat. Vorläufiger Abfluss wird zu genehmigtem Abfluss, und die Zahl bewegt sich.
Eine Sitzung speichert ein Bündel aus ihrem Manifest und den Antwortkörpern, die sie gesehen hat. Die Wiedergabe läuft in drei Modi, und die Unterscheidung zwischen ihnen ist der Punkt.
Modus | Verfahren | isoliert |
| Neuberechnung aus den archivierten Körpern | Code- und Bibliotheksänderung |
| erneut abrufen, identische Antworten verlangen | jede Abweichung überhaupt |
| erneut abrufen, diffen, den Dienst bitten, jede Differenz zu erklären | Datenrevision |
with Session(question="what was the discharge in mid May 2021?") as work:
Toolkit(work).get_series("USGS-02344872", "00060", "2021-05-16", "2021-05-20")
work.save("bundle.json")gagelink-replay bundle.json --mode strict
gagelink-replay bundle.json --mode revision_awareDasselbe Bündel, derselbe erneute Abruf und zwei verschiedene Urteile:
strict replay: changed
changed daily
[changed] USGS-02344872 00060 at 2021-05-16: 702.1 -> 826.0 ft^3/s
revision_aware replay: reproduced
changed daily
[revised] USGS-02344872 00060 at 2021-05-16: 702.1 -> 826.0 ft^3/s,
Revisions: Discharge for the period May 16, 2021 to Oct. 27, 2021,
was revised on Aug. 16, 2024, based on changes to the estimated discharge.Ein Ergebnis, das sich änderte, weil die Behörde 400 vorläufige Werte revidiert hat, ist eine andere Tatsache über die Wissenschaft als eines, das sich änderte, weil sich der Code änderte, und die beiden sind ansonsten nicht zu unterscheiden. Der Revisionsdatensatz stammt aus der eigenen time-series-revisions-Sammlung des Dienstes, verknüpft über die Zeitreihenkennung, die die Messung bereits trägt, sodass die Zuordnung eine Nachschlageoperation und keine Vermutung ist. Eine Differenz ohne veröffentlichte Revision dahinter bleibt als unerklärt gemeldet, was die Prüfung davor bewahrt, nichtssagend zu sein.
Körper werden vor jedem Vergleich gegen ihre Hashes verifiziert. Ein Bündel, dessen Archiv nicht übereinstimmt, wird abgelehnt und nicht abgespielt, da jedes Urteil darauf beruht, dass das Archiv das ist, was die Sitzung tatsächlich gesehen hat.
bench/ ist ein Benchmark, der misst, was das Toolkit einem Modell wert ist, über neun Aufgaben an einer Station, die neun Gefahren abdecken, jede davon in einer Live-Dienst-Payload beobachtet, während das Paket gebaut wurde.
Drei Bedingungen werden auf identischen Daten verglichen, die sich nur in der Schnittstelle zwischen dem Modell und den Bytes unterscheiden:
Bedingung | Was das Modell erhält |
| Ein Fetch-Tool, das das eigene JSON des Dienstes zurückgibt, was ein Entwickler heute hat |
| Die elf Tools mit Ergebnissen auf nackte Größen reduziert und die Notizen entfernt |
| Die Tools wie sie sind, mit Einheiten, Bezugssystemen, Qualität, Veralterung und den Notizen |
Die mittlere Bedingung ist das, was die Messung wertvoll macht. Ohne sie würde ein Unterschied zwischen der ersten und der letzten nur zeigen, dass strukturierter Abruf rohes JSON schlägt, was niemand bezweifelt. Der Unterschied zwischen den letzten beiden ist das, was die Metadaten für sich genommen wert sind.
python -m bench --dry-run # no provider, no spend
python -m bench --model anthropic/claude-opus-5 --replicates 4Jede erwartete Antwort wird aus denselben aufgezeichneten Antworten abgeleitet, die die Tools bedienen, und tests/test_bench.py löst jede Aufgabe aus diesen Antworten und prüft das Ergebnis gegen die deklarierte Antwort. Eine Aufgabe, deren Antwort auf diese Weise nicht erreicht werden kann, ist eine kaputte Aufgabe, und genau dort zeigt es sich. Jede Aufgabe protokolliert auch eine basis, die angibt, woher ihre Zahl stammt, sodass ein Leser sie überprüfen kann, ohne das Wort dieses Projekts zu nehmen.
Die Freibord-Aufgabe ist gegen die eigene Arithmetik der Behörde prüfbar: USGS veröffentlicht die Wasseroberflächenhöhe als Parameter 63160, bei 40,07 ft NAVD88, was die Pegelhöhe von 3,03 ft plus dem Bezugshöhenversatz der Station von 37,04 ft ist.
Die Bewertung wird geschrieben, bevor ein Durchlauf stattfindet, und steht unter Versionskontrolle, sodass eine Regel nicht angepasst werden kann, nachdem ein Ergebnis gesehen wurde, das sie benachteiligt.
gpt-oss-120b, neun Aufgaben, drei Bedingungen, acht Wiederholungen, 216 Läufe, 0,09 $.
Bedingung | Korrekt |
| 61/72 |
| 63/72 |
| 70/72 |
Korrektheit zählt jeden Lauf, einschließlich der acht, die ohne Antwort endeten. Sieben davon gehören zu http_only bei den beiden Aufgaben, deren roher Datensatz 42.000 und 50.000 Prompt-Token umfasst, wo das Modell degeneriert und eine Zahl wiederholt, statt zu antworten. Diese Fehler werden durch die Bedingung verursacht, sodass ihr Ausschluss rohem JSON für die Läufe gutschreiben würde, die seine eigene Payload-Größe zerstört hat.
Die Suite liegt bei sechs von neun Aufgaben an der Obergrenze, was eine Erkenntnis über die Suite ist. Wo sie trennt:
Aufgabe |
|
|
|
| 3/8 | 8/8 | 8/8 |
| 6/8 | 8/8 | 8/8 |
| 8/8 | 1/8 | 7/8 |
Bei den beiden Aufgaben mit langen Datensätzen betrug der Median-Prompt 49.864 und 42.006 Token durch rohes JSON gegenüber 5.462 und 2.384 durch das Toolkit. Bei der Aufgabe mit undurchsichtiger Einheit schickte das Entfernen der Referenzrahmen sieben von acht Läufen in die aufgezeichnete Falle, die mit dem USGS-Abfluss von 3010 ft³/s antworteten statt mit den 2,95 kcfs des Vorhersagedienstes.
Das Toolkit schlägt rohes JSON bei der Genauigkeit im Allgemeinen nicht. Die Lücke wird fast vollständig durch die beiden Aufgaben getrieben, bei denen die rohe Payload nicht passt. Acht von 27 Zellen verteilt über ihre Wiederholungen, sodass Unterschiede unter etwa zwei Läufen von acht durch dieses Design nicht getrennt werden, und ein Modell ist ein Modell.
Der Dienst erlaubt 50 Anfragen pro IP und Stunde ohne Authentifizierung und 1.000 pro Stunde mit einem Schlüssel, der kostenlos unter api.waterdata.usgs.gov/signup erhältlich ist. Eine einzelne Agentenfrage, die Bedingungen an fünf Standorten vergleicht, kostet etwa 15 bis 25 Anfragen, daher ist Caching tragend und keine Optimierung, und Antworten werden standardmäßig für die Lebensdauer des Prozesses zwischengespeichert.
Das verbleibende Kontingent wird aus X-RateLimit-Remaining auf jeder Antwort gelesen und auf dem Abruf mitgeführt, sodass einem Agenten mitgeteilt werden kann, was ihm noch bleibt, anstatt das Limit durch Scheitern zu entdecken.
Der Schlüssel reist im X-Api-Key-Header und erscheint nie in einer aufgezeichneten URL, da ein Manifest zur Veröffentlichung gedacht ist.
USGS stellt die WaterServices-API-Familie ein, mit der Einstellung geplant für das erste Quartal 2027 und möglicher Verschlechterung ab der zweiten Hälfte 2026. gagelink zielt nur auf den Ersatz unter api.waterdata.usgs.gov/ogcapi/v0. Eine Konsequenz, die es wert ist, genannt zu werden, ist die time-series-revisions-Sammlung, die Änderungen und Löschungen an genehmigten Aufzeichnungen veröffentlicht und die es einer Wiedergabe ermöglichen wird, eine Antwort, die sich änderte, weil die Behörde eine Messung revidiert hat, von einer zu trennen, die sich änderte, weil sich der Code änderte.
python3 -m venv .venv
.venv/bin/pip install -e ".[dev]"
.venv/bin/pytestNetzwerkzugriff erfolgt über ein austauschbares fetch, sodass die Suite gegen aufgezeichnete Antworten läuft und kein Test das Netzwerk benötigt.
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.
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.