cdc-health-mcp-server

List CDC Catalog Vocabulary

cdc_list_catalog_vocabulary

Read-only

List the controlled vocabularies cdc_discover_datasets' category and tags filters are matched against — every domain category and domain tag the CDC catalog publishes, each with the number of entries carrying it. Call it before filtering a search: a value the catalog does not carry matches nothing and returns an empty page, which is indistinguishable from a real value with no results. All 55 categories come back whole; the tag vocabulary runs to roughly 1,600 values, so tags are ranked by entry count and returned one page at a time via tag_limit and tag_offset. Pass filter to narrow both vocabularies to the values whose words contain it.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domain`	No	CDC Socrata host to read the vocabulary from. "data.cdc.gov" (default) and "chronicdata.cdc.gov" front the same catalog and publish the same vocabulary, so this selects which host answers, never which values exist.	data.cdc.gov
`filter`	No	Narrow both vocabularies to the values related to this text. A value matches when every word of the filter appears inside one of its words ("vaccin" reaches "Vaccinations" and "covid-19 vaccination"), or when the whole value appears in the filter. Matching is not fuzzy — a misspelling returns nothing rather than a guess — and a filter under three letters is ignored.
`tag_limit`	No	Tags to return in this call (default 50, max 500). Tags are ranked by entry count, so the default page is the most-used end of the vocabulary; the response reports how many matched and a nextOffset while more remain. Categories are never paged — all 55 arrive whole.
`tag_offset`	No	Index of the first tag to return, for continuing past a previous call (default 0). Ranking is stable, so tag_offset plus tag_limit walks the vocabulary without gaps or repeats. An offset at or past the number of matching tags returns an empty tag list rather than an error.

Output Schema

TableJSON Schema

Name	Required	Description
`cap`	No	The tag_limit that bounded this response.
`tags`	No	The requested window of domain tags, ranked by entry count. Pass values to cdc_discover_datasets' tags input; tags union there, so each one added widens the result set.
`error`	No	Present when the call failed. Absent on success.
`shown`	No	Number of tags returned in this response.
`domain`	No	CDC Socrata host this vocabulary was read from.
`notice`	No	Guidance when the response is a subset of the vocabulary, when a filter too short to discriminate was ignored, when the filter matched nothing, or when tag_offset ran past the end of the matches.
`tagCount`	No	Tags matching the filter, before tag_limit and tag_offset.
`truncated`	No	True when the returned tags are a subset of the matching ones. Absent means every matching tag is in this response.
`categories`	No	Every domain category matching the filter, ranked by entry count. Pass a value to cdc_discover_datasets' category input exactly as spelled here.
`nextOffset`	No	Value to pass as tag_offset on the next call to continue after the last tag returned. Present only while matching tags remain.
`categoryCount`	No	Categories matching the filter. Every one of them is in this response.
`vocabularySize`	No	Size of each full vocabulary on this host, before any filter was applied.
`truncationCeiling`	No	Upper bound on the entry count of every tag not returned. Tags are ranked by entry count, so no omitted tag is carried by more entries than the last one shown.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 20, 2026

TDQS

A5/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the text exposes meaningful behaviors: all 55 categories are returned whole, tags are paginated by entry count, under-three-letter filters are ignored, matching is not fuzzy, and out-of-range offsets return an empty list rather than an error. This is far more than annotations alone convey.

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?

The purpose is front-loaded in the first sentence, and each subsequent clause adds operational detail (pagination, matching rules, filter behavior) rather than repeating schema content. The length is justified by the complexity of pagination and matching semantics.

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 an output schema present and no required parameters, the description covers the important runtime contingencies: empty-page ambiguity, pagination continuation, filter matching edge cases, and host selection. An agent has enough to invoke the tool correctly without further research.

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?

Even though the schema already documents all four parameters (100% coverage), the description adds non-obvious semantics: domain selects the host but never the available vocabulary, tag_limit is the most-used end with nextOffset reporting, and tag_offset exploits stable ranking without gaps. This meaningfully exceeds the schema text.

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 opens with a specific verb and resource: it lists the controlled vocabularies that cdc_discover_datasets' category and tag filters match against, including counts. This clearly differentiates it from the data-retrieval siblings by identifying the exact catalogs and purpose.

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?

It explicitly instructs 'Call it before filtering a search' and justifies the order by explaining that unsupported values yield an empty page indistinguishable from a valid value with no results. It also tells when to use filter and tag_limit/tag_offset, giving an agent concrete call sequencing.

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

All cdc-health-mcp-server tools Inspect

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.