Skip to main content
Glama

noaa-climate-mcp-server

Get NOAA Billion-Dollar Disasters

noaa_climate_get_billion_dollar_disasters
Read-only

Query NOAA/NCEI’s Billion-Dollar Weather and Climate Disasters — the curated record of US disasters whose damage passed $1 billion, with CPI-adjusted and unadjusted costs, deaths, and one of seven classes (Drought, Flooding, Freeze, Severe Storm, Tropical Cyclone, Wildfire, Winter Storm). Every cost returned is in WHOLE US DOLLARS: NCEI declares a different unit in each export — millions for the per-event file, billions for the national per-year file — and this server converts from whichever unit the file declares, echoing it back as declaredCostUnit. Default calls return individual disasters; summary=true returns per-year counts and costs by class plus an "All Disasters" total. Filter with startYear/endYear (a disaster overlapping either end is included), disasterType (exactly as NCEI writes it, e.g. "Tropical Cyclone"), minCostInUsd, and state (a two-letter US postal code). Coverage runs from 1980 to the last year NCEI has finished assessing — currently 2024, not the current calendar year — and coveredYears reports what the export holds. Under a state scope, per-event rows are national disasters that reached that state and carry the NATIONAL cost, never a state share, so summing states double-counts; per-year rows carry a binned cost range instead of a point estimate. This is a different NOAA corpus from the CDO tools and from noaa_climate_search_storm_events: no token, and the curated set of major disasters rather than every severe-weather event.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of disasters or years to return (1–100). Defaults to 50.
stateNoTwo-letter US postal code (e.g. "CA", "TX", "PR") scoping the query to NCEI’s per-state export instead of the national one. Per-event rows then carry the national cost of each disaster that reached the state, not a state share; per-year rows carry a binned cost range instead of a point estimate. Optional.
offsetNoZero-based index of the first matching record to return. Defaults to 0.
endYearNoLatest year to include (1980 or later). NCEI publishes a year only once its assessment settles, so a year past coveredYears.last returns nothing rather than an error. Optional.
summaryNoReturn per-year counts and costs by disaster class instead of individual disasters. Defaults to false.
startYearNoEarliest year to include (1980 or later). A disaster whose span reaches into the range is included even when it began earlier. Optional — omit for the whole record.
disasterTypeNoRestrict to one NCEI disaster class, written exactly as NCEI writes it. In summary mode this also drops the "All Disasters" total from each year, leaving only the named class. Optional.
minCostInUsdNoFloor on CPI-adjusted cost in whole US dollars — 1e9 is one billion. In summary mode this is compared against the year’s "All Disasters" total, or against the named disasterType when one is given; where only a binned range exists, the top of the bin has to clear the floor. Optional.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe limit that was applied. Omitted otherwise.
modeNoWhich shape this response carries: "events" populates disasters, "summary" populates summaries.
errorNoPresent when the call failed. Absent on success.
scopeNo"US" for the national record, or the two-letter state code that was requested.
shownNoRecords returned on this page. Omitted otherwise.
noticeNoGuidance when nothing matched or the page ran past the end. Omitted otherwise.
costBasisNoPresent when a state scope is queried in events mode: every cost below is the NATIONAL cost of a disaster that reached the state, not that state’s share of it, so adding states together double-counts. Omitted for the national scope and in summary mode.
disastersNoIndividual disasters for the requested page. Present when mode is "events".
exhaustedNoTrue when offset is past the end of a non-empty match set — the page is empty but matches exist. Omitted otherwise.
summariesNoPer-year tallies for the requested page. Present when mode is "summary".
truncatedNoTrue when more matches exist beyond this page. Omitted otherwise.
sourceFileNoThe exact NCEI export this response was read from, e.g. "events-US.csv".
totalCountNoRecords matching every filter across the whole export, before offset and limit.
coveredYearsNoThe year span the export actually holds, read from its rows.
declaredCostUnitNoThe cost unit this export declares in its own preamble, e.g. "millions of dollars". Every cost below is already in whole US dollars; this names the unit it was converted from.

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses critical behavioral details: the unit conversion (whole US dollars with declaredCostUnit), the state-scope caveats (national cost not state share, double-counting risk, binned cost ranges for per-year rows), and the coverage window (1980 to assessed year, not current calendar). It even warns about overlap inclusion rules and the difference between per-event and per-year outputs.

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 dense paragraph but every sentence carries unique value—no filler. It front-loads the primary purpose and then layers in filtering, unit, and state-scope nuances. While it is lengthy, it is appropriately compact for the complexity (8 optional parameters, two output modes); a bulleted format would improve skimmability but is not necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with high complexity and subtle edge cases, the description covers all critical aspects: the two output modes (default vs summary), filtering semantics, cost unit conversion, state-scope double-counting warning, coverage years, and the distinction from other NOAA tools. It even explains the meaning of coveredYears and the binned cost range, so an agent has everything needed to call it correctly without additional probing.

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

Parameters5/5

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

Though schema coverage is 100% and the schema already provides rich parameter descriptions, the description adds essential semantics beyond the schema: the exact overlap rule for startYear/endYear, the state parameter's effect on row types and cost interpretation, the minCostInUsd behavior in summary mode (compared against 'All Disasters' or bin tops), and the 'coveredYears' reporting. This goes well beyond the baseline and significantly aids correct invocation.

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 states a specific verb ('Query') and a precise resource (NOAA/NCEI's Billion-Dollar Weather and Climate Disasters) while naming the exact content (curated disasters, cost classes, unit handling). It explicitly distinguishes itself from sibling tools by naming noaa_climate_search_storm_events and the CDO tools, so an agent can immediately tell this is a different corpus.

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 explicit when-to-use guidance: it contrasts itself with the CDO tools and noaa_climate_search_storm_events, explains that it covers curated major disasters rather than every severe-weather event, and details default vs summary modes. It also clarifies the coverage years and how filters behave, leaving no ambiguity about when to choose this tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: fetching data, searching locations, searching stations, getting station metadata, listing categories/datasets/types, and listing location categories. No two tools overlap; an agent can easily select the correct one based on the task.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case: fetch_data, find_locations, find_stations, get_station, list_data_categories, list_datasets, list_data_types, list_location_categories. The verbs (fetch, find, get, list) are semantically appropriate and predictable.

Tool Count5/5

With 8 tools, the server is well-scoped for a climate data API. It covers the essential discovery and retrieval workflow without unnecessary bloat. Each tool serves a clear role in fetching or finding climate data elements.

Completeness5/5

The tool set provides a complete workflow: discover datasets, data categories, data types, location categories, find locations, find stations, get station metadata, and fetch observation data. There are no obvious gaps for the stated purpose of accessing NOAA climate data.