Search and query CDC public health data — mortality, vaccinations, surveillance, behavioral risk.
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.
Average 4.2/5 across 4 of 4 tools scored.
Each tool has a clearly distinct role: discovery, schema inspection, Socrata querying, and WONDER querying. The descriptions explicitly cross-reference each other (e.g., discover returns IDs used by get_schema and query_dataset), and the WONDER tool is clearly separated as a different system.
All tool names follow a consistent cdc_ verb_noun pattern: discover_datasets, get_dataset_schema, query_dataset, query_wonder. The prefix and underscore style are uniform, making the set highly predictable.
With 4 tools, the set is compact yet covers the core workflow for both CDC data systems it targets. There are no redundant tools, and each adds a meaningful capability without overwhelming the agent.
For the domain of read-only CDC data access, the tool surface is complete: find datasets, inspect schemas, query Socrata data, and query WONDER mortality data. There are no obvious dead ends or missing operations for typical data exploration workflows.
cdc_discover_datasetsCdc Discover DatasetsASearch 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"). |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, covering safety. The description adds useful details like 'truncated descriptions' and 'column counts', but doesn't disclose pagination or other behaviors beyond what the schema already explains. This is adequate but not rich.
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 purpose and search dimensions, followed by return fields and a sibling pointer. Every sentence earns its place with zero waste.
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 a full input schema, output schema, and readOnlyHint annotation, the concise description is sufficient. It clearly scopes the tool as catalog search and differentiates it from schema retrieval. The presence of output schema eliminates the need to describe return values in detail.
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 input schema has 100% description coverage for all 7 parameters, so the baseline is 3. The description only echoes 'keyword, category, or tag', which maps to existing params, adding no new parameter semantics.
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 the specific verb 'Search', identifies the resource 'CDC dataset catalog', and lists search dimensions (keyword, category, tag) plus return fields. It explicitly points to cdc_get_dataset_schema for full column lists, distinguishing it from that sibling tool.
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 directs users to cdc_get_dataset_schema for full column lists, providing an explicit alternative for the next step. However, it doesn't mention when to use cdc_query_dataset or cdc_query_wonder for data retrieval, so exclusion guidance is incomplete.
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 SchemaAFetch 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. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes safety, and the description adds behavioral detail by disclosing exactly what is returned (schema, 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?
The description is a single, well-structured sentence that conveys all essential information without redundancy. Every part 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 simple parameter set, readOnlyHint annotation, and presence of an output schema, the description is complete. It covers prerequisites and return contents adequately.
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 valuable guidance by referencing cdc_discover_datasets as the source for datasetId, enhancing parameter meaning beyond the raw 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 the tool fetches the full column schema for a CDC dataset, listing specific contents (names, data types, descriptions, row count, last-updated timestamp). This distinguishes it from sibling tools like cdc_discover_datasets (discovery) and cdc_query_dataset (querying).
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 instructs users to get dataset IDs from cdc_discover_datasets, providing a clear prerequisite and sequencing. It does not explicitly state when not to use this tool, but the context 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_datasetCdc Query DatasetAExecute 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. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool executes a SoQL query and lists capabilities, but provides no additional behavioral context such as response format, pagination behavior, error handling, or rate limits. The only annotation (readOnlyHint=true) already covers read-only nature, and the description adds no extra disclosure beyond that.
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, front-loaded with the core action, followed by a compact capability list and a terse pointer to sibling tools. 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?
The description provides essential context: what the tool does, its capabilities, and the prerequisite sibling tools. It doesn't address the cdc_query_wonder alternative or any operational caveats, but the comprehensive schema and output schema compensate, making it adequate for a complex SoQL tool.
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%, with each of the 10 parameters already documented in rich detail (e.g., quoting rules, backtick advice, max limits). The description's capability list is a high-level summary that adds no new meaning beyond the schema, so the baseline of 3 applies.
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 opens with 'Execute a SoQL query against any CDC dataset' – a specific verb and resource. It lists five distinct capabilities (filtering, aggregation, sorting, full-text search, field selection) and explicitly names sibling tools for discovery and schema inspection, distinguishing this as the querying tool.
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?
Clear guidance is given to use cdc_discover_datasets for dataset IDs and cdc_get_dataset_schema for column inspection before querying. However, it doesn't contrast with the sibling cdc_query_wonder, leaving ambiguity about which query tool to use in which scenario.
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 WonderAQuery 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. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, it discloses meaningful behaviors: suppression of cells with fewer than 10 deaths (returned as null), a ~15-second rate limit, and API-level policy restricting sub-national data. These are valuable operational details an agent needs to interpret results and manage request pacing correctly.
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 pack in the essential information: purpose, scope, data source timeframe, key limitations, suppression behavior, and rate limiting. Each sentence earn its place, and the description is well-structured with the core purpose front-loaded.
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 rich input schema, output schema, and readOnlyHint annotation, the description covers the remaining contextual gaps: it names the exact database (D76, 1999–2020), clarifies national vs. sub-national data availability, warns about cell suppression, and mentions rate limiting. This is sufficient for an agent to select and invoke the tool 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?
Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds a helpful overview of grouping/filtering dimensions and repeats that cause is a filter, but it does not materially extend the schema's parameter semantics—it largely restates what is already in the input 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 opens with a specific verb and resource: "Query CDC WONDER for national US mortality statistics — deaths, population, and crude/age-adjusted death rates." It distinguishes this tool from siblings by noting "WONDER is a separate CDC system from the Socrata datasets the other cdc_* tools query," making the tool's niche 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?
It clearly states this tool is for national mortality statistics and that sub-national breakdowns are unavailable. The sibling distinction (Socrata vs. WONDER) provides contextual guidance for selecting between tools, though it does not explicitly name alternative tools or give exclusions beyond the national-only limitation.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.
