Skip to main content
Glama
Sign In

Gillby

by io.github.OneWave-AI
OverviewDiscussionsAdmin

Observed station rainfall history

get_rainfall_history
Read-onlyIdempotent

Observed daily precipitation from NOAA NCEI GHCN-Daily at one of six selected Florida airport stations, not archived forecasts. Required station, start and end (YYYY-MM-DD); completed dates only, 1900 onward, at most 366 inclusive days per request. Public, no API key. Returns daily values in inches, original flags, coverage, monthly summaries and totals. totalIn is null for incomplete coverage; partialTotalIn is only the sum of accepted reported values. Trace is not dry. Presumed-zero, incomplete-period and quality-flagged reports are excluded. Reporting dates are station climate days, not UTC hours. A station does not measure rainfall at a nearby beach, inlet or across a region. Recent records may lag or be revised. Use for how much precipitation fell: NOAA observed station records, not forecast archives. Preserve station, reporting dates, trace days, missing/excluded counts and coverage. Never present partialTotalIn as a complete monthly/yearly total. Station rainfall is not an area-wide measurement. Use get_rain for future amounts and get_history source=forecast:om_weather_best var=precip_in only for archived model estimates. Units: ft, kt, s, F, mi; directions FROM. Returns data and source/freshness metadata.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "get_rainfall_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial behavior beyond that: no API key, 1900+ and a 366-day-per-request cap, completed dates only, null totalIn on incomplete coverage, partialTotalIn semantics, trace not dry, exclusion of presumed-zero/flagged reports, station climate days rather than UTC, and revision lag.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense and mostly front-loaded, but it repeats the same idea twice ('not archived forecasts' and later 'not forecast archives'), and the trailing 'Units: ft, kt, s, F, mi; directions FROM' is boilerplate borrowed from a marine/wind tool that is irrelevant to rainfall reported in inches and mildly confusing.

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?

With no output schema, the description carries the return burden and does so: daily values in inches, original flags, coverage, monthly summaries and totals, plus the null/partial semantics that an agent would otherwise guess wrong. Nothing material is missing for a read-only historical lookup.

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?

With 0% documented schema coverage the description must carry the parameters, and it does: station is required and constrained to six Florida airport stations, start/end are YYYY-MM-DD, dates must be completed and from 1900 onward, and the span is capped at 366 inclusive days. It adds real constraint meaning over the schema, though it does not restate the enum-to-airport mapping that the enum description already supplies.

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

Purpose5/5

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

States a specific verb+resource with full provenance: 'Observed daily precipitation from NOAA NCEI GHCN-Daily at one of six selected Florida airport stations, not archived forecasts.' It also names the siblings it is not, so an agent can distinguish it from get_rain and get_history without opening either schema.

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?

Explicit when-to-use ('Use for how much precipitation fell'), explicit when-not ('not forecast archives'), and names two alternatives with the exact conditions and parameters that select them ('get_rain for future amounts and get_history source=forecast:om_weather_best var=precip_in only for archived model estimates'). Nothing is left to inference.

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

All Gillby toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources