Skip to main content
Glama

Cdc Query Wonder

cdc_query_wonder
Read-only

Query CDC WONDER for national US mortality statistics — deaths, population, and crude/age-adjusted death rates — across its five mortality databases, selected with the database input: final underlying-cause data for 1999–2020 (the default) or 2018–2024, provisional data running from 2018 through the current year, and two multiple-cause databases covering the same two eras. Break results out by year, age group, sex, and/or race, and filter by ICD-10 cause of death, sex, age group, or year range; on a multiple-cause database, mcd_icd10 additionally matches a cause listed anywhere on the death certificate rather than only the one certified as underlying. Each database holds a different span of years (1999–2026 across all of them) and a request whose year_range falls outside the selected one's span is rejected with that span named. WONDER is a separate CDC system from the Socrata datasets the other cdc_* tools query. Data is national only — sub-national (state/county) breakdowns are not available through the API (CDC vital-statistics policy). Cause of death is a filter, not a grouping. Some measure cells come back as a CDC status token rather than a number — "Suppressed" (withheld for confidentiality), "Unreliable" (a rate from fewer than 20 deaths), or "Not Applicable" (no population denominator); those cells read null in rows and each one is listed in cellNotes with its token. CDC also drops whole rows before sending the table — strata with zero deaths, and strata whose death count is suppressed — so a stratum can be missing from rows entirely; messages carries CDC's statement whenever that happened. The whole table comes back by default; a broad grouping can run past a thousand rows, so set limit to take it a page at a time and follow the nextOffset the response reports. Paging shapes the response only — WONDER is asked once either way, and the figures, caveats and hidden-row notices are the same on every page. CDC rejects requests made less than 15 seconds apart across all five databases, so consecutive calls are spaced automatically and a follow-up call may wait about 16 seconds before it runs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sexNoFilter by sex.all
limitNoRows to return from the table CDC sent (1–5000). Omit to return the whole table. WONDER's request carries no limit of its own, so this pages a table already fetched in full rather than narrowing the query: the deaths, rates, caveats and hidden-row notices are the same whichever page is read. A four-dimension grouping can run past a thousand rows, so set this and follow nextOffset to walk them.
offsetNoIndex of the first row to return, for continuing past a previous call (default 0, max 10,000). Rows keep the order CDC returned them in, which is stable for a given query, so offset plus limit walks the table without gaps or repeats. An offset at or past the row total returns an empty page rather than an error.
databaseNoWhich WONDER mortality database to query. "underlying_1999_2020" (D76) is final data for 1999–2020 and the default. "provisional" (D176) runs 2018 through the current year, updated weekly, and returns the most recent years labelled e.g. "2025 (provisional)". "underlying_2018_2024" (D158) is settled — not provisional — data for 2018–2024. "multiple_1999_2020" (D77) and "multiple_2018_2024" (D157) record every cause listed on the death certificate; without an mcd_icd10 filter they return the same figures as the underlying-cause database for the same era, so pick one only to use that filter. The two 1999–2020 databases report race in CDC's four bridged groups; the other three use the six single-race groups — figures broken out by race are not comparable between the two families.underlying_1999_2020
group_byNoDimensions to break results out by (1–4), in output-column order — e.g. ["year"], ["year","sex"], ["age_group","race"]. Results are always national. Cause of death is a filter (cause_icd10), not a grouping. "race" resolves to whichever race vocabulary the selected database uses — four bridged groups (Asian and Pacific Islander combined) on the 1999–2020 databases, six single-race groups plus a multiracial category on the others — so a race series from one family cannot be spliced onto one from the other.
mcd_icd10NoFilter to deaths with this ICD-10 code recorded anywhere on the death certificate, whether or not it was the underlying cause — e.g. "died with a respiratory condition listed", a population no underlying-cause query can produce. Valid only when database is "multiple_1999_2020", "multiple_2018_2024", or "provisional"; the other databases record only the underlying cause and reject it. "999--999", the withheld-cause marker described under cause_icd10, is offered here too but only by "provisional". Combines with cause_icd10, which keeps meaning the underlying cause. Omit for all causes.
age_groupsNoRestrict to deaths in any of the listed age groups — e.g. ["25-34","35-44"] covers both. "1" is the under-1-year group. "NS" is the group CDC puts a death in when the age was not recorded; it is not covered by any of the ten-year groups, so a filter listing all eleven of those still leaves those deaths out and returns fewer deaths than the same query unfiltered. List "NS" alongside them to match an unfiltered total, or on its own to count them. Omit for all ages, which includes them.
year_rangeNoInclusive year range. These bounds span every database (1999–2026); the years the selected one actually holds are narrower, and a range outside them is rejected with that database's span named. Omit for all years the database holds.
cause_icd10NoFilter to a specific ICD-10 underlying cause of death — the single condition CDC certified as having started the chain of events leading to death. Omit for all causes. Accepted by every database. "999--999" is not an ICD-10 code but CDC's own marker for deaths whose cause it is still withholding under the provisional database's six-month reporting lag; it counts that backlog, and only the "provisional" database offers it.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe requested limit that bounded this response.
rowsNoResult rows. Each carries the requested group-by dimensions plus deaths, population, crude_rate, and age_adjusted_rate (per 100,000) when age standardization is possible — it is omitted when age_group is a grouping dimension or age_groups selects a single group. Dimension values are CDC's own labels with only surrounding whitespace removed, so the same year keys identically across databases; nothing inside a label is changed, and on the provisional database a year reads "2025 (provisional)" or "2026 (provisional and partial)" rather than a bare year. A measure cell CDC returned as a status token instead of a number is null here; cellNotes names the cell and the token. When limit or offset is set these are one page of the table CDC sent, in its order; totalCount says how many rows the whole table holds.
errorNoPresent when the call failed. Absent on success.
shownNoNumber of rows returned in this response.
noticeNoGuidance when no rows matched, when the returned rows are a page of a larger table or the offset ran past it, and a note when CDC returned a status token in place of a measure value.
caveatsNoCDC-provided caveats and footnotes: data revisions, population-estimate sources, suppression and rate-reliability rules. They describe the whole table CDC assembled, so they come back complete on every page rather than scoped to the rows returned.
databaseNoWONDER dataset code the rows came from — e.g. "D76", "D176", "D157".
messagesNoNotices CDC attached to this table, verbatim. The ones that matter say rows were withheld before the table was sent — "Rows with zero Deaths are hidden." and "Rows with suppressed Deaths are hidden." A withheld row is absent from rows entirely, with nothing in the table marking the gap, so while this array is non-empty a stratum missing from rows may have been dropped rather than unobserved, and any count, ranking, or completeness claim drawn from rows is partial. These describe the whole table, so they come back complete on every page. Empty when CDC withheld no rows.
rowCountNoNumber of rows returned in this response — the page size when limit or offset is set.
cellNotesNoOne entry per measure cell CDC returned as a status token rather than a number, covering the rows in this response only. Those cells read null in rows, so this is what tells a withheld value apart from an unreliable one or a genuinely absent one.
truncatedNoTrue when rows remain past the ones returned. Absent means this response runs to the end of the table, which is also the case for an offset past it.
nextOffsetNoOffset to pass on the next call to resume immediately after the last row returned. Present only when further rows remain.
totalCountNoRows in the whole table CDC returned, before limit/offset. Exact rather than estimated — the table is parsed in full before a page is taken from it.
databaseTitleNoCDC's own title for that database, e.g. "Underlying Cause of Death, 1999-2020". Names the era and record type the rows describe, so a result read on its own is self-describing.
effectiveQueryNoHuman-readable summary of the grouping and filters sent to WONDER.
suppressedCountNoHow many cellNotes carry the "Suppressed" token — cells CDC withheld for confidentiality. Counted over the rows in this response, so it tracks the page rather than the whole table.

TDQS

A5/5.0
Behavior5/5

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

Annotations indicate readOnlyHint, but the description goes far beyond by detailing response behavior (paging, hidden rows, cellNotes, nextOffset), the impact of rate limiting, and database-specific quirks (e.g., race vocabulary mismatch, withheld-cause markers).

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

Conciseness5/5

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

Though lengthy, every sentence carries essential information for a complex tool. The description is logically organized (purpose, data scope, paging, rate limits) and avoids redundancy, justified by the tool's many interacting parameters and quirks.

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 output schema exists, the description adequately covers all aspects: input parameters, response shape (mentions rows, nextOffset, messages, cellNotes), and operational constraints. It leaves no gaps for an agent to understand how to call and interpret results.

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?

Schema coverage is 100%, and the description enriches every parameter with nuanced semantics, such as how limit affects the already-fetched table, how NS age groups interact with filters, and the difference between underlying and multiple cause filters.

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 (Query), resource (CDC WONDER), and clearly distinguishes from siblings by focusing on national mortality statistics and explicitly noting it is a separate CDC system from the Socrata datasets used by other cdc_* tools.

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?

Provides explicit usage guidance: contrasts with other CDC tools, explains when to use each database (underlying vs provisional vs multiple), and gives practical advice on paging with limit/offset and the automatic spacing of calls.

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.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: discovering datasets, fetching schemas, querying Socrata data, and querying WONDER data. Even though query_dataset and query_wonder both execute queries, they operate on entirely separate systems and are explicitly differentiated in the descriptions, eliminating any ambiguity.

Naming Consistency5/5

All tools follow a consistent cdc_verb_noun pattern: discover_datasets, get_dataset_schema, query_dataset, query_wonder. The naming is uniform, predictable, and clearly indicates the action and target.

Tool Count4/5

Four tools is lean but sufficient for the server's scope: three tools cover the full Socrata dataset lifecycle (discover, schema, query) and one handles the separate WONDER system. The count is slightly on the low end but not inadequate, and each tool is essential.

Completeness4/5

The tool surface covers the primary workflows for searching, inspecting, and querying CDC datasets and WONDER data. Minor gaps exist, such as no direct way to list all datasets without a search, but the provided tools handle the core use cases without dead ends.