Skip to main content
Glama

List Census Predicate Values

census_list_predicate_values
Read-only

List the codes a Census filter dimension accepts, so a predicates map can be written without guessing. Answers the question left open when census_query_data or census_compare_geographies reports that a dimension was left unset. Which route a dimension takes depends on the vintage: NAICS and POPGROUP always publish a value list in the dataset dictionary, and on the current vintages EMPSZES, LFO, RCPSZES, TAXSTAT, and TYPOP publish none and are enumerated here against the live data endpoint instead. A dictionary value list is a classification shared across Census products rather than a list of what one dataset serves, and roughly half of its codes typically return no rows anywhere — those are checked against the dataset's own published rows and dropped, and the response source field says whether that check ran. The dictionary lists run to thousands of codes and are best narrowed with query. Pass the returned code as the dimension's value in predicates.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearNoVintage year (default: latest available for the dataset).
limitNoMaximum codes to return (default: 50, max: 500).
queryNoKeyword to narrow the list, matched case-insensitively against each code and label (e.g., "software" against NAICS2017, "exempt" against TAXSTAT). Omit to list from the start. NAICS and POPGROUP run to thousands of codes, so a keyword is the practical way to use them.
datasetYesDataset the dimension belongs to (e.g., "cbp", "nonemp", "ecnbasic", "dec/ddhca", "pep/charv"). Use census_list_datasets to discover valid values. Dimension codes are vintage-specific, so the dataset and year must match the query the values are for.
predicateYesFilter dimension code to enumerate (e.g., "EMPSZES", "LFO", "POPGROUP", "NAICS2017"). Case-sensitive. The response notice of census_query_data names the dimensions a dataset declares, and census_search_variables finds them by keyword.
within_naicsNoIndustry code to scope the enumeration by, for dimensions the Census publishes per industry. On ecnbasic, TAXSTAT and TYPOP return only the all-establishments row until a NAICS sector is named — pass a sector code such as "62" (Health Care) or "42" (Wholesale Trade) and the result is complete for that industry alone. Ignored for dimensions with a published value list. Get sector codes by calling this tool on the dataset's own NAICS dimension. Blank is treated as omitted.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearNoVintage year queried.
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when the list was truncated, when query matched no published code, when codes from the dataset dictionary could not be checked against its published rows, or when the codes returned are complete only for a named industry rather than for the dimension as a whole.
sourceNoWhere the codes came from. "live_query" is a wildcard group-by against the data endpoint, which returns only codes the dataset publishes. "dataset_dictionary_verified" is the dataset's published value map with the codes it serves no rows for removed. Plain "dataset_dictionary" is that map unchecked — every code in it is declared by the dataset, but some of them return nothing at any geography, and the notice says why the check did not run.
valuesNoCodes the dimension accepts, sorted by code.
datasetNoDataset queried.
predicateNoFilter dimension enumerated.
truncatedNoTrue when totalCount exceeds the limit and the list was cut.
totalCountNoCodes matched before the limit was applied.
predicate_labelNoLabel of the dimension itself (e.g., "Employment size of establishments code").

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

The annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds substantial behavioral detail: dictionary lists are shared classifications, codes that return no rows are dropped, and the response source field indicates whether that check ran. It also warns that dictionary lists run to thousands of codes and benefit from query narrowing, which goes well beyond the structured annotations.

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 description is dense but every sentence earns its place: core purpose is front-loaded, then usage context, then behavioral caveats, then practical guidance. No filler or restatement of the title.

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 six parameters, two required, and an output schema, the description covers purpose, when to use it, how to avoid pitfalls, parameter relationships, and post-call behavior. The presence of an output schema means return-value documentation is already handled elsewhere, so nothing essential is missing.

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%, so the baseline is 3, but the description goes much further. It explains the special behavior of within_naics for TAXSTAT and TYPOP on ecnbasic, gives concrete query examples, notes case-sensitivity for predicate, and explains why dataset and year must align. This adds real operational meaning beyond the raw parameter descriptions.

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 and resource: 'List the codes a Census filter dimension accepts'. It also explains the exact use case (writing predicates without guessing) and connects to sibling tools by addressing the gap left when census_query_data or census_compare_geographies reports a dimension unset.

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 explicitly says when to use the tool — when a dimension was left unset — and names discovery alternatives: census_list_datasets for datasets and census_search_variables for predicate dimensions. It also explains the vintage-dependent routing between dictionary value lists and live endpoint enumeration, so an agent knows how the tool behaves in each case.

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.