census-mcp-server

Resolve Census Geography

census_resolve_geography

Read-only

Resolve a place name or street address to Census FIPS identifiers. Converts names like "King County, WA", "Seattle, WA", or "Seattle-Tacoma-Bellevue, WA" to the codes required by census_query_data and census_compare_geographies. Use before querying when you have a place name rather than raw FIPS codes — state_fips maps to parent_fips and fips_summary maps to geography_fips in downstream tools, and geography_type is itself the geography_level to query at.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Place name (e.g., "King County, WA", "Seattle, WA", "California") or street address (e.g., "1600 Pennsylvania Ave NW, Washington, DC 20500"). Include the state abbreviation to disambiguate places with common names — it narrows a statistical area as well, matching any state the area spans, so "Kansas City, MO" and "Kansas City, KS" both reach the MO-KS metro area. For a statistical area, the name is the full hyphenated one the Census publishes ("Seattle-Tacoma-Bellevue, WA" for the metro area, "Seattle-Tacoma, WA" for the combined one) — a single city name matches it too when only one area contains that city.
`county_fips`	No	County FIPS code to resolve within — 1 to 3 digits, zero-padded here to the 3 the Census stores. A tract name is unique only inside its county, so a bare tract name matching two counties comes back as ambiguous_name until this is set: take the countyFips of the candidate you want from that error and re-call. Only county and tract sit within a county, so this restricts resolution to those two levels — pairing it with any other geography_type, or with a street address, is a county_scope_unsupported error rather than a scope quietly dropped. census_query_data takes the same code as its own county_fips but pads nothing, so hand it the 3-digit county_fips returned here, not the shorter value.
`geography_type`	No	Geography level to resolve to, named exactly as census_query_data's geography_level and census_list_geographies name it. Auto-detection covers only state, county, place, and tract: state for a two-letter abbreviation or a spelled-out state name, county when the name contains "County"/"Borough"/"Parish", tract when it contains "Tract", otherwise place with a fallback to county. The other three are never auto-detected and must be set explicitly, because their names overlap city names — "metropolitan statistical area/micropolitan statistical area" covers both metro and micro areas and yields a 5-digit code, "combined statistical area" yields a 3-digit code, and "consolidated city" covers the eight merged city-county governments (Nashville-Davidson, Louisville/Jefferson County, Indianapolis, Athens-Clarke County, Augusta-Richmond County, Butte-Silver Bow, Milford CT, Greeley County KS). Setting it explicitly also overrides auto-detection — "New York" auto-detects as the state, so New York City needs "place".

Output Schema

TableJSON Schema

Name	Required	Description
`name`	No	Canonical name of the resolved geography.
`error`	No	Present when the call failed. Absent on success.
`place_fips`	No	Place FIPS code when the resolved geography is an incorporated place.
`state_fips`	No	2-digit state FIPS code. Use as parent_fips in census_query_data for sub-state queries. Absent for a metropolitan/micropolitan or combined statistical area, which can span several states and needs no parent_fips.
`tract_fips`	No	6-digit census tract FIPS code when the resolved geography is a tract — from a street address, or from a tract name.
`county_fips`	No	3-digit county FIPS code when the resolved geography is a county or sub-county level.
`fips_summary`	No	Pre-formatted FIPS value ready to use as geography_fips in census_query_data (e.g., "033" for King County with state_fips "53" as parent_fips, "42660" for the Seattle-Tacoma-Bellevue metro area with no parent at all).
`geography_type`	No	Resolved geography level. Pass this straight through as geography_level in census_query_data and census_compare_geographies.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 19, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnlyHint, the description discloses auto-detection scope (state/county/place/tract only), explicit override behavior, ambiguity errors (ambiguous_name), county_scope_unsupported errors, and Census padding conventions. No contradiction 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.

Conciseness5/5

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

The three-sentence description front-loads the purpose, uses concrete examples, and packs downstream routing and auto-detection caveats into a compact, high-density text. Every sentence earns its place.

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 resolver with an output schema, a read-only annotation, and only one required parameter, the description plus parameter docs cover use cases, disambiguation, error states, and downstream integration. Nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents all three parameters at 100% coverage, so the baseline is 3. The description adds downstream field mapping (state_fips to parent_fips, fips_summary to geography_fips), but this mostly concerns output values rather than input parameter semantics, so it does not push beyond the schema's substantial 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-resource pair: 'Resolve a place name or street address to Census FIPS identifiers.' It provides concrete examples and explicitly ties the output codes to census_query_data and census_compare_geographies, which distinguishes it from all sibling data-retrieval 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?

It directly says 'Use before querying when you have a place name rather than raw FIPS codes,' giving an explicit precondition and routing decision. It also explains how the returned fields map into downstream tools, so an agent knows exactly when this tool is the necessary first step.

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

All census-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.