cdc-health-mcp-server
Server Details
Search and query CDC public health data — mortality, vaccinations, surveillance, behavioral risk.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/cdc-health-mcp-server
- GitHub Stars
- 3
- Server Listing
- cdc-health-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: discover datasets, get schema, query SoQL datasets, and query WONDER mortality. No overlap or ambiguity.
All tools follow a consistent 'cdc_verb_noun' pattern (e.g., discover_datasets, get_dataset_schema, query_dataset, query_wonder), making naming predictable.
Four tools cover the essential operations for CDC health data: discovery, schema inspection, querying the main dataset system, and a separate tool for WONDER mortality. Well-scoped.
The tool set provides complete CRUD-like coverage for read-only access: discover datasets, inspect schema, query data, plus access to an additional data source (WONDER). No obvious gaps for the intended domain.
Available Tools
4 toolscdc_discover_datasetsCdc Discover DatasetsARead-onlyInspect
Search the CDC dataset catalog by keyword, category, or tag. Returns dataset IDs, names, truncated descriptions, column counts, and update timestamps. Use cdc_get_dataset_schema for the full column list of a chosen dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Filter by domain tags (e.g., ["covid19", "surveillance"]). | |
| limit | No | Results to return (default 10, max 100). | |
| order | No | Result ordering. "dataset_id" (default) sorts deterministically by each dataset's unique catalog ID — required for stable offset pagination, since consecutive pages form a gap-free, duplicate-free traversal. "relevance" returns best-match ranking for keyword search but is not stably paginable across pages, so walking offsets can skip or repeat datasets. | dataset_id |
| query | No | Full-text search across dataset names and descriptions (e.g., "diabetes mortality", "lead exposure children"). | |
| domain | No | CDC Socrata portal to search. "data.cdc.gov" (default) is the main CDC catalog; "chronicdata.cdc.gov" hosts chronic-disease and small-area datasets (PLACES, the Heart Disease & Stroke Atlas, Environmental Public Health Tracking). | data.cdc.gov |
| offset | No | Pagination offset for browsing beyond first page (max 9999). | |
| category | No | Filter by domain category (e.g., "NNDSS", "Vaccinations", "Behavioral Risk Factors"). |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no datasets matched — echoes the applied filters and suggests how to broaden the search. |
| datasets | Yes | Matching datasets. |
| totalCount | Yes | Total matching datasets in the catalog (for pagination). |
| appliedFilters | Yes | Filters applied to this query; absent fields indicate no filter on that dimension. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with the read-only search nature. The description adds valuable behavioral details beyond annotations, such as truncated descriptions, stable pagination behavior for different order modes, and domain-specific portal distinction.
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 crisp sentences that immediately convey the tool's purpose and output, with no extraneous words. It earns its place.
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 complexity (7 parameters, full schema coverage, annotations, and output schema), the description is complete. It covers what the tool does, what it returns, and provides a pointer to a sibling tool for deeper schema details.
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%, so the baseline is 3. The description adds extra meaning by elaborating on the 'order' parameter's pagination behavior and the 'domain' parameter's portal distinction, which is not present in the schema descriptions.
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 searches the CDC dataset catalog by keyword, category, or tag, and specifies the returned fields (dataset IDs, names, truncated descriptions, column counts, update timestamps). It also distinguishes from siblings by naming cdc_get_dataset_schema for full column details.
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 provides direct guidance on when to use cdc_get_dataset_schema instead, but does not explicitly state exclusions or when not to use this tool. The context is clear enough for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cdc_get_dataset_schemaCdc Get Dataset SchemaARead-onlyInspect
Fetch the full column schema for a CDC dataset — names, data types, descriptions, row count, and last-updated timestamp. Get dataset IDs from cdc_discover_datasets.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | CDC Socrata portal hosting the dataset. Use the same portal you found the dataset on via cdc_discover_datasets: "data.cdc.gov" (default) or "chronicdata.cdc.gov". | data.cdc.gov |
| datasetId | Yes | Four-by-four dataset identifier (e.g., "bi63-dtpu"). Obtain from cdc_discover_datasets. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | Dataset display name from the catalog (e.g., "Provisional COVID-19 Deaths by Sex and Age"). |
| columns | Yes | Dataset columns with types and descriptions. |
| rowCount | No | Total number of rows when reported by upstream; omitted when unknown. |
| updatedAt | No | Last data update timestamp when provided. |
| description | No | Dataset description when provided. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; the description adds value by specifying exactly what the schema includes (column details, row count, timestamp). No contradictions with annotations.
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, no redundancy. The first sentence immediately states the purpose and deliverables, the second provides crucial upstream dependency.
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 presence of an output schema and comprehensive parameter docs, the description sufficiently covers all needed context: what it does, how to obtain inputs, and what the output includes. The added details about row count and timestamp are helpful.
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% with detailed descriptions for both parameters. The description reinforces that datasetId comes from cdc_discover_datasets, but does not add substantial new semantic meaning beyond the schema.
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 'Fetch the full column schema' with specific elements (names, data types, descriptions, row count, last-updated timestamp), distinguishing it from sibling tools cdc_discover_datasets and cdc_query_dataset.
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 instructs to get dataset IDs from cdc_discover_datasets, providing a clear sequential usage pattern. However, it does not explicitly state when not to use this tool (e.g., for querying data instead of schema).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cdc_query_datasetCdc Query DatasetARead-onlyInspect
Execute a SoQL query against any CDC dataset. Supports filtering, aggregation, sorting, full-text search, and field selection. Use cdc_discover_datasets to find dataset IDs and cdc_get_dataset_schema to inspect columns before querying.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | SoQL GROUP BY clause. Requires aggregate functions in select. | |
| limit | No | Max rows to return (default 100, max 5000). | |
| order | No | SoQL ORDER BY clause. Field name with optional ASC/DESC: "total_deaths DESC". | |
| where | No | SoQL WHERE clause. Strings must be single-quoted: "state='California' AND year=2020". If a column name matches a SoQL keyword (group, select, where, order, limit, offset, having, search), wrap it in backticks: "`group`='By Year'". | |
| domain | No | CDC Socrata portal hosting the dataset. Must match the portal the dataset lives on: "data.cdc.gov" (default) or "chronicdata.cdc.gov" (PLACES and other chronic-disease/small-area datasets). | data.cdc.gov |
| having | No | SoQL HAVING clause. Filters aggregated results. | |
| offset | No | Row offset for pagination (max 1,000,000). | |
| search | No | Full-text search across all text columns. For precise filtering use the where parameter instead. | |
| select | No | SoQL SELECT clause — column names, aliases, or aggregates: "state, sum(deaths) as total_deaths". Omit for all columns. To enumerate distinct values of a column, set select to "{column}, count(*) as count" with group="{column}" and order="count DESC". | |
| datasetId | Yes | Four-by-four dataset identifier (e.g., "bi63-dtpu"). Obtain from cdc_discover_datasets. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The requested limit that bounded this response. |
| rows | Yes | Result rows with requested fields. Most values are strings (including numbers/dates); geo columns return GeoJSON objects. |
| shown | No | Number of rows returned in this response. |
| notice | No | Guidance when no rows matched or results were truncated — how to verify filters, paginate, or broaden the query. |
| rowCount | Yes | Number of rows returned in this response. |
| truncated | No | True when the result row count hit the requested limit and may be incomplete. |
| effectiveQuery | Yes | Assembled SoQL query string sent to the Socrata API. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's read-only. The description adds that it supports various query features, which is consistent with the schema. No additional behavioral traits (e.g., rate limits) 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?
Two sentences, front-loaded with the core action, no redundant or extraneous information.
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 schema has full coverage and an output schema exists, the description is complete. It mentions prerequisite tools and explains the query capabilities. Minor omissions like pagination details are covered by schema.
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%, so each parameter already has a description. The tool description only generally mentions supported operations; it does not add significant meaning beyond what the schema provides.
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 executes SoQL queries on CDC datasets and lists supported operations (filtering, aggregation, sorting, full-text search, field selection). It distinguishes from sibling tools by referencing them as preliminary steps.
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 tells the agent to use cdc_discover_datasets and cdc_get_dataset_schema before querying, providing clear guidance on when to use this tool. However, it does not explicitly exclude other scenarios, but it is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cdc_query_wonderCdc Query WonderARead-onlyInspect
Query CDC WONDER for national US mortality statistics — deaths, population, and crude/age-adjusted death rates — from the Underlying Cause of Death database (D76, 1999–2020). 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. 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. CDC suppresses any cell with fewer than 10 deaths (returned as null). The API is rate-limited to one request every ~15 seconds, so requests may be briefly spaced.
| Name | Required | Description | Default |
|---|---|---|---|
| sex | No | Filter by sex. | all |
| group_by | No | Dimensions 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. | |
| age_groups | No | Restrict to specific ten-year age groups — e.g. ["25-34","35-44"]. "1" is the under-1-year group. Omit for all ages. | |
| year_range | No | Inclusive year range within 1999–2020. Omit for all years. | |
| cause_icd10 | No | Filter to a specific ICD-10 underlying cause of death. Omit for all causes. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | Yes | Result rows. Each carries the requested group-by dimensions plus deaths, population, crude_rate, and — unless grouped by age_group — age_adjusted_rate (per 100,000). Suppressed measure cells (< 10 deaths) are null. |
| notice | No | Guidance when no rows matched, or a note that CDC suppressed some cells. |
| caveats | Yes | CDC-provided caveats and footnotes: data revisions, population-estimate sources, suppression and rate-reliability rules. |
| database | Yes | WONDER database queried (D76 — Underlying Cause of Death, 1999–2020). |
| rowCount | Yes | Number of rows returned. |
| effectiveQuery | Yes | Human-readable summary of the grouping and filters sent to WONDER. |
| suppressedCount | Yes | Number of measure cells CDC suppressed (< 10 deaths), returned as null. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description adds behavioral traits such as rate limiting (~15 seconds), suppression of cells with fewer than 10 deaths, and cause as a filter. This goes beyond what annotations provide.
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?
Every sentence serves a purpose. The description is structured to first state the tool's function, then detail parameters, constraints, and behavioral notes. No unnecessary repetition or fluff.
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 complexity (5 parameters, nested objects, output schema present), the description covers all necessary information: data source, year range, grouping behavior, filters, limitations (national only, cell suppression), and rate limit. The presence of an output schema reduces the need to describe return values, but the description still provides context on what is returned.
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 100%, but the description adds significant meaning: explains cause_icd10 format, group_by ordering, age_group values, year_range inclusivity, and the fact that cause is not a grouping. This is well above the baseline 3.
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 queries CDC WONDER for national mortality statistics, specifies the database, year range, and available breakdowns. It also distinguishes itself from sibling tools by noting WONDER is separate from Socrata datasets.
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 says when to use this tool (for national mortality stats) and when not to (sub-national data unavailable). It also clarifies differences from sibling tools and constraints like cause being a filter, not a grouping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.