Skip to main content
Glama
mattpodwysocki

Census MCP Server

by mattpodwysocki
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Census MCP Server

npm version CI codecov License: MIT Node.js Version

Node.js server implementing Model Context Protocol (MCP) for U.S. Census Bureau APIs.

Access Census Data Through AI

The Census MCP Server enables AI agents and applications to access comprehensive U.S. demographic and economic data from the Census Bureau. With this server, your AI can retrieve and analyze:

  • American Community Survey (ACS) - Demographics, income, employment, education, housing

  • Decennial Census (2020, 2010) - Complete population counts every 10 years

  • Population Estimates - Annual population estimates by age, sex, race

  • County Business Patterns - Business establishment counts, employment, payroll

  • Economic Census - Comprehensive business statistics every 5 years

  • Geographic Information - Land area, water area, centroid coordinates for any geography

  • Census Geocoding - Convert addresses to coordinates and find Census geographies

  • TIGERweb Boundaries - Retrieve actual geographic boundary polygons as GeoJSON

  • Health Insurance Estimates - Health insurance coverage by county and demographic groups

  • Public Sector Employment - Government employment and payroll statistics

  • Poverty Statistics - Poverty estimates and median income for states and counties

  • Rental Housing Finance - Financial and mortgage characteristics of rental properties

  • Annual Business Survey - Business ownership by demographics (sex, ethnicity, race, veteran status)

  • Community Resilience Estimates - Neighborhood social vulnerability and disaster resilience

  • International Database - Global population data for 200+ countries (1950-2100)

  • Quarterly Workforce Indicators - Employment, job creation, hires, separations, earnings by demographics and industry

  • Business Dynamics Statistics - Job creation/destruction, business births/deaths, firm startups/shutdowns

  • Geographic levels - National, state, county, tract, place, and more

  • Historical data - Access data from 1950 to present, with projections to 2100

Whether you're building a demographic analysis tool, location intelligence application, policy research assistant, or any application that needs U.S. census data, the Census MCP Server provides direct access to official government statistics.

Related MCP server: geographic-data

Usage

A Census API key is required to use this MCP server.

To get a free Census API key:

  1. Visit https://api.census.gov/data/key_signup.html

  2. Fill out the signup form with your organization and email

  3. You'll receive your API key via email instantly

Installation

Using npm

npm install -g @bluerfalcon/census-mcp-server

Using npx (no installation required)

npx @bluerfalcon/census-mcp-server

Configuration

Claude Desktop Setup

Add to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "census": {
      "command": "npx",
      "args": ["-y", "@bluerfalcon/census-mcp-server"],
      "env": {
        "CENSUS_API_KEY": "your_census_api_key_here"
      }
    }
  }
}

Environment Variables

Create a .env file in your project directory:

CENSUS_API_KEY=your_census_api_key_here
CENSUS_API_ENDPOINT=https://api.census.gov/data/  # optional

Available Resources

MCP Resources provide read-only access to Census vocabularies and metadata. Use these to discover available data before querying with tools.

1. ACS Variables Resource

Browse available variables for American Community Survey datasets.

URI Patterns:

  • census://acs/2022/acs5/variables - All variables for 2022 ACS 5-year estimates

  • census://acs/2021/acs1/variables - All variables for 2021 ACS 1-year estimates

  • census://acs/2022/acs5/variables?group=B01001 - Variables in specific group (e.g., B01001 = Age/Sex)

Returns: JSON with variable codes, labels, concepts, and groups

Example Use:

Read census://acs/2022/acs5/variables?group=B19013 to see median income variables

2. Census Variables Resource

Browse available variables for various Census datasets. This is a generic resource that works across multiple Census APIs.

URI Patterns:

  • census://variables/healthins/sahie - Health Insurance variables

  • census://variables/popest - Population Estimates variables

  • census://variables/idb/1year - International Database variables

  • census://variables/govs - Public Sector Employment variables

  • census://variables/poverty/saipe - Poverty Statistics variables

  • census://variables/rhfs - Rental Housing Finance variables

  • census://variables/abs - Annual Business Survey variables

  • census://variables/cre - Community Resilience Estimates variables

  • census://variables/cbp - County Business Patterns variables

  • census://variables/ecnbasic - Economic Census variables

  • census://variables/dec/pl - Decennial Census variables

  • census://variables/qwi - Quarterly Workforce Indicators variables

  • census://variables/bds - Business Dynamics Statistics variables

Returns: JSON with variable codes, labels, and descriptions for the specified dataset

Example Use:

Read census://variables/healthins/sahie to see all health insurance variables
Read census://variables/cre to see community resilience variables

3. State FIPS Codes Resource

Get all US state and territory FIPS codes.

URI: census://geography/states

Returns: JSON list of all states with FIPS codes, names, and abbreviations

Example Use:

Read census://geography/states to see all state codes

Available Tools

1. ACS Data Tool

Retrieve demographic and economic data from the American Community Survey (ACS).

Parameters:

  • year: Year for ACS data (e.g., 2022)

  • dataset: "acs1" (1-year estimates) or "acs5" (5-year estimates, default)

  • variables: Array of Census variable codes (e.g., ["B01001_001E", "B19013_001E"])

  • geography: Geographic level ("us", "state", "county", "tract", "place")

  • state: State FIPS code (required for county/tract/place geographies)

  • county: County FIPS code (required for tract geography)

Common Variables:

  • B01001_001E - Total population

  • B19013_001E - Median household income

  • B25077_001E - Median home value

  • B23025_005E - Unemployment count

Find more variables: ACS 5-Year Variables

2. Decennial Census Tool

Retrieve data from the U.S. Decennial Census (2020, 2010).

Parameters:

  • year: "2020" or "2010"

  • dataset: "pl" (redistricting), "dhc" (demographics), or "sf1" (summary file)

  • variables: Array of variable codes (e.g., ["P1_001N", "P2_002N", "H1_001N"])

  • geography: Geographic level ("us", "state", "county", "tract", "block group", "place")

  • state: State FIPS code (required for sub-state geographies)

  • county: County FIPS code (required for tract/block group)

Common Variables:

  • P1_001N - Total population

  • P1_003N - White alone population

  • P1_004N - Black or African American alone

  • P2_002N - Hispanic or Latino population

  • H1_001N - Total housing units

Find more variables: 2020 Census Variables

3. Population Estimates Tool

Retrieve annual population estimates from the Population Estimates Program (PEP).

Parameters:

  • year: Vintage year (2020-present, default: 2023)

  • variables: Array of variables (default: ["POP"])

  • geography: Geographic level ("us", "state", "county")

  • state: State FIPS code (required for county)

  • ageGroup: Age group code (optional filter)

  • sex: "0" (both), "1" (male), "2" (female)

  • hispanicOrigin: "0" (both), "1" (non-Hispanic), "2" (Hispanic)

Common Variables:

  • POP - Population estimate

  • AGE - Age group code

  • SEX - Sex code

  • POPGROUP - Race/ethnicity group

  • HISP - Hispanic origin

Find more variables: PEP Variables

4. County Business Patterns Tool

Retrieve business statistics from County Business Patterns (CBP).

Parameters:

  • year: Year for CBP data (1986-present, typically 2 years behind)

  • variables: Array of variables (default: ["ESTAB", "EMP", "PAYANN"])

  • geography: Geographic level ("us", "state", "county")

  • state: State FIPS code (required for county)

  • naics: NAICS industry code (2-6 digits)

  • employmentSizeClass: Employment size code

Common Variables:

  • ESTAB - Number of establishments

  • EMP - Number of employees

  • PAYANN - Annual payroll ($1,000s)

  • PAYQTR1 - First quarter payroll ($1,000s)

  • NAICS2017 - Industry code

Common NAICS Codes:

  • 72 - Accommodation and food services

  • 541 - Professional, scientific, and technical services

  • 44-45 - Retail trade

  • 62 - Health care and social assistance

Find more variables: CBP Variables

5. Economic Census Tool

Retrieve comprehensive business statistics from the Economic Census (every 5 years).

Parameters:

  • year: "2017", "2012", or "2007"

  • variables: Array of variables (default: ["ESTAB", "EMP", "RCPTOT", "PAYANN"])

  • geography: Geographic level ("us", "state", "county", "metro area")

  • state: State FIPS code (optional for state, required for county)

  • county: County FIPS code (optional)

  • naics: NAICS industry code (2-6 digits)

  • sector: NAICS sector code (2 digits)

Common Variables:

  • ESTAB - Number of establishments

  • EMP - Number of employees

  • RCPTOT - Sales/receipts/revenue ($1,000s)

  • PAYANN - Annual payroll ($1,000s)

  • VALADD - Value added ($1,000s)

Find more variables: Economic Census Variables

6. Geographic Information Tool

Retrieve geographic metadata and reference information from the Census Bureau Geographic Information API.

Parameters:

  • year: Vintage year for geographic data (2020-present, default: 2023)

  • variables: Array of geographic variables (see below for common options)

  • geography: Geographic level ("us", "state", "county", "tract", "place", "congressional district")

  • state: State FIPS code (required for county, tract, place, congressional district)

  • county: County FIPS code (required for tract)

Common Variables:

  • NAME - Geographic area name

  • AREALAND - Land area (square meters)

  • AREALAND_SQMI - Land area (square miles)

  • AREAWATR - Water area (square meters)

  • AREAWATR_SQMI - Water area (square miles)

  • INTPTLAT - Internal point latitude (centroid)

  • INTPTLON - Internal point longitude (centroid)

Example queries:

  • "Get land and water area for California"

  • "Show me the geographic metadata for all states"

  • "What are the coordinates for the centroid of Los Angeles County?"

Find more info: Geographic Information API

7. Census Geocoding Tool

Convert addresses to coordinates or find Census geographies for any U.S. location. No API key required.

Parameters:

  • searchType: "onelineaddress" (default), "address" (structured), or "coordinates" (reverse)

  • address: Single line address string (for onelineaddress)

  • street, city, state, zip: Structured address components (for address search)

  • longitude, latitude: Coordinates (for reverse geocoding)

  • returnGeographies: Return geographic hierarchies (default: true)

  • benchmark: Benchmark version (default: Public_AR_Current)

  • vintage: Geography vintage (default: Current_Current)

Returns:

  • Coordinates (latitude/longitude)

  • Matched address

  • All Census geographies containing that location:

    • States, Counties, Places

    • Census Tracts, Block Groups, Blocks

    • Metropolitan Statistical Areas

    • Congressional Districts

    • ZIP Code Tabulation Areas

Example queries:

  • "What Census tract is 1600 Pennsylvania Avenue in?"

  • "Geocode this address: 123 Main St, San Francisco, CA"

  • "What county contains coordinates 37.7749, -122.4194?"

8. TIGERweb Boundary Tool

Retrieve actual geographic boundary polygons as GeoJSON. No API key required.

Parameters:

  • geographyType: "state", "county", "tract", "block group", or "place"

  • state: State FIPS code or 2-letter abbreviation

  • county: County FIPS code (required for tract/block group)

  • tract: Census tract code (required for block group)

  • geoid: Full GEOID to query specific feature

  • name: Search by name (e.g., "California")

  • vintage: Data vintage (default: Current)

  • simplify: Return simplified geometries (default: false)

Returns:

  • GeoJSON FeatureCollection with boundary polygons

  • Can be used directly in mapping libraries

  • Includes properties: GEOID, NAME, land area, etc.

Example queries:

  • "Get the boundary polygon for California"

  • "Show me the GeoJSON for Los Angeles County"

  • "Get all Census tracts in San Francisco County"

Find more info: TIGERweb Documentation

9. Health Insurance Estimates Tool

Retrieve health insurance coverage estimates from the Small Area Health Insurance Estimates (SAHIE) program.

Parameters:

  • year: Year for estimates (2006-2023, default: 2022)

  • variables: Array of variables (see below for common options)

  • geography: Geographic level ("us", "state", "county")

  • state: State FIPS code (required for county, optional for state)

  • county: County FIPS code (optional for specific county)

  • ageCategory: Age group filter ("0": Under 65, "1": 18-64, "2": 40-64, "3": 50-64, "4": Under 19, "5": 21-64)

  • incomeRange: Income category ("0": All, "1": ≤138% poverty, "2": ≤200%, "3": ≤250%, "4": ≤400%)

  • raceEthnicity: Race/ethnicity ("0": All, "1": White non-Hispanic, "2": Black, "3": Hispanic)

Common Variables:

  • NIC_PT - Number of people with health insurance

  • NUI_PT - Number of people without health insurance

  • PCTIC_PT - Percent with health insurance

  • PCTUI_PT - Percent without health insurance

  • NIPR_PT - Number in poverty range

  • PCTLIIC_PT - Percent low-income with insurance

Example queries:

  • "What percent of people in California have health insurance?"

  • "Show me uninsured rates for all counties in Texas"

  • "Get health insurance coverage for people under 65 in Florida"

Find more info: SAHIE Documentation

10. Public Sector Employment Tool

Retrieve government employment and payroll statistics from the Annual Survey of Public Employment & Payroll.

Parameters:

  • year: Year for data (2017-2024, default: 2024)

  • variables: Array of variables (see below for common options)

  • geography: Geographic level ("us", "state")

  • state: State FIPS code (optional for specific state)

  • governmentType: Filter by government type ("state", "local", "combined")

Common Variables:

  • TOT_EMP - Total employment (full-time + part-time)

  • FT_EMP - Full-time employment

  • PT_EMP - Part-time employment

  • TOT_PAY - Total payroll (in thousands)

  • FT_PAY - Full-time payroll (in thousands)

  • PT_PAY - Part-time payroll (in thousands)

  • TOT_HRS - Total hours worked

  • FT_HRS - Full-time hours

  • PT_HRS - Part-time hours

Example queries:

  • "How many state government employees does California have?"

  • "Show me total government employment and payroll by state"

  • "What is local government employment in Texas?"

  • "Compare state vs local government employees across all states"

Find more info: Public Employment Documentation

11. Poverty Statistics Tool

Retrieve poverty estimates and median household income from the Small Area Income and Poverty Estimates (SAIPE) program.

Parameters:

  • year: Year for estimates (1989-2022, default: 2022)

  • variables: Array of variables (see below for common options)

  • geography: Geographic level ("us", "state", "county")

  • state: State FIPS code (required for county, optional for state)

  • county: County FIPS code (optional for specific county)

Common Variables:

  • SAEPOVALL_PT - Poverty count (all ages)

  • SAEPOVRTALL_PT - Poverty rate percentage (all ages)

  • SAEPOV0_17_PT - Children in poverty (ages 0-17)

  • SAEPOVRT0_17_PT - Child poverty rate (ages 0-17)

  • SAEPOV5_17R_PT - School-age children in poverty (ages 5-17)

  • SAEPOVRT5_17R_PT - School-age poverty rate (ages 5-17)

  • SAEPOV0_4_PT - Young children in poverty (ages 0-4)

  • SAEPOVRT0_4_PT - Young child poverty rate (ages 0-4)

  • SAEMHI_PT - Median household income

Example queries:

  • "What is the poverty rate in California?"

  • "Show me child poverty rates for all counties in Mississippi"

  • "Get poverty statistics and median income for all states"

  • "Compare poverty rates across states"

  • "What percent of children are in poverty in Texas counties?"

Find more info: SAIPE Documentation

12. Rental Housing Finance Tool

Retrieve rental housing finance data from the Rental Housing Finance Survey (RHFS).

Parameters:

  • year: Year for data ("2015", "2018", "2021", default: "2021")

  • group: Data group to retrieve (required, see below)

  • propertySize: Filter by property size (optional, see below)

Data Groups:

  • RHFS_PC - Property Configuration (building counts, unit counts, year built, etc.)

  • RHFS_EX - Expenses (operating expenses, utilities, maintenance, etc.)

  • RHFS_OM - Ownership and Management (ownership type, management, etc.)

  • RHFS_IS - Income and Subsidies (rental income, government subsidies, etc.)

  • RHFS_FM - Finances and Mortgage (mortgage status, refinancing, debt, etc.)

  • RHFS_CI - Capital Improvements and Expenses (renovations, capital projects, etc.)

Property Size Filters:

  • 0 - All properties (default)

  • 1 - 1 unit properties

  • 2 - 2-4 unit properties

  • 3 - 5-24 unit properties

  • 4 - 25-49 unit properties

  • 5 - 50+ unit properties

Returns:

  • Property counts and unit counts

  • Detailed characteristics based on selected group

  • Margins of error for estimates

  • National-level data only (no state/county breakdown)

Example queries:

  • "Get property configuration data for rental housing in 2021"

  • "Show me rental housing expenses for properties with 5-24 units"

  • "What are the financing characteristics of rental properties?"

  • "Get income and subsidies data for single-unit rental properties"

Note: RHFS provides national-level statistics only and is available for years 2015, 2018, and 2021.

Find more info: RHFS Documentation

13. Annual Business Survey Tool

Retrieve business ownership data from the Annual Business Survey (ABS). Replaced the Survey of Business Owners (SBO) in 2017.

Parameters:

  • year: Year for data (2017-2023, default: 2023)

  • variables: Array of variables (see below for common options)

  • geography: Geographic level ("us", "state", "county", "metro area")

  • state: State FIPS code (required for county, optional for state)

  • county: County FIPS code (optional for specific county)

  • sex: Owner sex ("001": All, "002": Male, "003": Female)

  • ethnicity: Owner ethnicity ("001": All, "002": Hispanic, "003": Non-Hispanic)

  • race: Owner race ("00": All, "10": White, "20": Black, "30": American Indian/Alaska Native, "40": Asian, "50": Native Hawaiian/Pacific Islander, "60": Two or more races)

  • veteran: Veteran status ("001": All, "002": Veteran, "003": Non-veteran)

Common Variables:

  • FIRMPDEMP - Number of employer firms

  • EMP - Number of employees

  • PAYANN - Annual payroll (in thousands)

  • RCPPDEMP - Receipts/sales (in thousands)

  • FIRMPDEMP_PCT - Percent of employer firms

  • EMP_PCT - Percent of employees

  • PAYANN_PCT - Percent of payroll

  • RCPPDEMP_PCT - Percent of receipts

Example queries:

  • "How many businesses are owned by women in California?"

  • "Get employer firms and employees for Hispanic-owned businesses by state"

  • "Show me veteran-owned business statistics for all states"

  • "What are the receipts for Asian-owned businesses in San Francisco County?"

  • "Compare business ownership by demographic groups across states"

Find more info: ABS Documentation

14. Community Resilience Estimates Tool

Retrieve community resilience and social vulnerability data from the Community Resilience Estimates (CRE).

Parameters:

  • year: Year for estimates ("2019", "2021", "2022", "2023", default: "2023")

  • variables: Array of variables (see below for common options)

  • geography: Geographic level ("us", "state", "county", "tract")

  • state: State FIPS code (required for county and tract, optional for state)

  • county: County FIPS code (required for tract, optional for specific county)

Common Variables:

  • PRED0_PE - Percent with zero vulnerability factors (most resilient)

  • PRED12_PE - Percent with 1-2 vulnerability factors (moderate)

  • PRED3_PE - Percent with 3+ vulnerability factors (high vulnerability)

  • PRED0_E - Count with zero vulnerability factors

  • PRED12_E - Count with 1-2 vulnerability factors

  • PRED3_E - Count with 3+ vulnerability factors

  • POPUNI - Total population universe

Vulnerability Components (8 factors):

  • Disability

  • Single-parent households with children under 18

  • Limited English proficiency

  • Poverty

  • No vehicle access

  • Crowded housing (>1.5 persons per room)

  • Group quarters (institutionalized population)

  • Age vulnerability (under 5 or 65+ years)

Example queries:

  • "What is the social vulnerability for all tracts in San Francisco County?"

  • "Show me community resilience estimates for California counties"

  • "Get neighborhood-level vulnerability data for census tracts in Los Angeles"

  • "Which neighborhoods have the highest disaster vulnerability in my county?"

  • "Compare resilience scores across states"

Perfect for: Real estate applications (Zillow-like), disaster preparedness, neighborhood risk assessment, emergency planning, community development.

Find more info: CRE Documentation

15. International Database Tool

Retrieve global population statistics from the U.S. Census Bureau International Database (IDB). Access population data for 200+ countries and territories worldwide from 1950 to 2100 (historical estimates and future projections).

Parameters:

  • year: Year for population data (1950-2100)

  • variables: Array of IDB variable codes (e.g., ["POP", "CBR", "E0"])

  • country: Optional FIPS country code (e.g., "CH" for China, "IN" for India, "US" for United States)

  • ageGroup: Optional age group filter (e.g., "0-4", "5-9", "10-14")

  • sex: Optional sex filter (0 = Both sexes, 1 = Male, 2 = Female)

Common Variables:

  • POP - Total population

  • CBR - Crude birth rate (births per 1,000 population)

  • CDR - Crude death rate (deaths per 1,000 population)

  • E0 - Life expectancy at birth (years)

  • GR - Population growth rate (percent)

  • IMR - Infant mortality rate (deaths per 1,000 live births)

  • MAB - Median age at birth (years)

  • TFR - Total fertility rate (births per woman)

  • NI - Natural increase (births minus deaths)

  • NM - Net migration (immigrants minus emigrants)

  • POP_DENS - Population density (persons per square kilometer)

  • AREA_KM2 - Land area (square kilometers)

Example queries:

  • "What is the current population and life expectancy for India?"

  • "Show me birth rates and death rates for all countries in 2024"

  • "Get population projections for Brazil from 2025 to 2050"

  • "Compare fertility rates across African countries"

  • "What is the population density and median age for China?"

Perfect for: International demographics, global population analysis, country comparisons, development indicators, migration studies, demographic projections.

Find more info: IDB Documentation

16. Quarterly Workforce Indicators Tool

Retrieve quarterly employment statistics from the Quarterly Workforce Indicators (QWI) program. Access 32+ economic indicators including employment levels, job creation/destruction, hires, separations, earnings, and turnover rates. Data available from 1990-present at state, county, metro area, and workforce investment board area levels.

Parameters:

  • year: Year for QWI data (1990-present)

  • quarter: Quarter (1-4)

  • variables: Array of QWI variable codes (e.g., ["Emp", "HirA", "Sep", "EarnS"])

  • geography: Geographic level (state, county, metro, wib)

  • state: Optional state FIPS code (required for county geography)

  • sex: Optional sex filter (0 = Both, 1 = Male, 2 = Female)

  • agegrp: Optional age group (A00 = All, A01 = 14-18, A02 = 19-21, A03 = 22-24, A04 = 25-34, A05 = 35-44, A06 = 45-54, A07 = 55-64, A08 = 65-99)

  • education: Optional education level (E0 = All, E1 = Less than high school, E2 = High school, E3 = Some college, E4 = Bachelor or advanced, E5 = Advanced degree)

  • race: Optional race filter (A0 = All, A1 = White, A2 = Black, A3 = American Indian/Alaska Native, A4 = Asian, etc.)

  • ethnicity: Optional ethnicity (A0 = All, A1 = Not Hispanic, A2 = Hispanic)

  • industry: Optional NAICS industry code (e.g., "00" = All, "54" = Professional services)

  • firmage: Optional firm age (0 = All, 1 = 0-1 years, 2 = 2-3 years, 3 = 4-5 years, 4 = 6-10 years, 5 = 11+ years)

  • firmsize: Optional firm size (0 = All, 1 = 0-19 employees, 2 = 20-49, 3 = 50-249, 4 = 250-499, 5 = 500+)

Common Variables:

  • Emp - Employment (number of jobs)

  • EmpS - Stable employment (workers employed at firm for full quarter)

  • HirA - Hires (all workers hired during quarter)

  • Sep - Separations (all workers who separated during quarter)

  • EarnS - Average earnings for stable workers

  • EarnBeg - Beginning-of-quarter earnings

  • EarnHirAS - Average earnings of hires

  • Payroll - Total payroll

  • TurnOvrS - Turnover rate (separations / average employment)

  • HirAS - Hire rate (hires / average employment)

  • SepS - Separation rate (separations / average employment)

  • JC - Job creation (net employment gains at expanding establishments)

  • JD - Job destruction (net employment losses at contracting establishments)

Example queries:

  • "What are the employment levels and average earnings in San Francisco County for Q1 2023?"

  • "Show me job creation and destruction rates for all states in Q4 2022"

  • "Get hiring rates for professional services (NAICS 54) by state for Q2 2023"

  • "Compare average earnings between male and female workers in California for Q3 2023"

  • "What are the turnover rates by age group in New York metro areas for Q1 2024?"

  • "Show me employment by education level for all counties in Texas for Q2 2023"

  • "Get job creation in young firms (0-1 years) for all states in Q4 2022"

Perfect for: Job market analysis, wage trends, employment dynamics, labor market research, workforce planning, economic development, evaluating areas for relocation.

Find more info: QWI Documentation

17. Business Dynamics Statistics Tool

Retrieve annual business dynamics statistics showing job creation, job destruction, establishment births/deaths, and firm startups/shutdowns. Track economic dynamism and business health from 1978-2023 at national, state, and metro/micro area levels.

Parameters:

  • year: Year for BDS data (1978-2023)

  • variables: Array of BDS variable codes (e.g., ["ESTABS", "JOB_CREATION", "JOB_DESTRUCTION"])

  • geography: Geographic level (us, state, metro)

  • state: Optional state FIPS code (required for metro geography, optional for state)

  • naics: Optional NAICS industry code (e.g., "00" = All, "54" = Professional services)

  • metro: Optional metro filter (0 = All, 1 = Filter applied, M = Metropolitan, N = Micropolitan/non-metro)

  • fage4: Optional firm age (a) 0 = Startups, b) 1-5, c) 6-10, d) 11-15, e) 16-20, f) 21-25, g) 26+)

  • fsize: Optional firm size (a) 1-4 employees, b) 5-9, c) 10-19, d) 20-49, e) 50-99, f) 100-249, etc.)

  • eage4: Optional establishment age (a) 0 = New, b) 1-5, c) 6-10, d) 11-15, etc.)

  • esize: Optional establishment size (a) 1-4 employees, b) 5-9, c) 10-19, d) 20-49, etc.)

Common Variables:

  • ESTABS - Number of establishments

  • ESTABS_ENTRY - New establishments (births)

  • ESTABS_EXIT - Closing establishments (deaths)

  • JOB_CREATION - Gross jobs created

  • JOB_DESTRUCTION - Gross jobs destroyed

  • NET_JOB_CREATION - Net job change (creation - destruction)

  • FIRMS - Number of firms

  • FIRMS_ENTRY - New firms (startups)

  • FIRMS_EXIT - Closing firms (shutdowns)

  • EMP - Employment level

  • JOB_CREATION_BIRTHS - Job creation from new establishments

  • JOB_CREATION_CONTINUERS - Job creation from expanding establishments

  • JOB_CREATION_RATE - Job creation rate (as percentage)

  • JOB_DESTRUCTION_DEATHS - Job destruction from closing establishments

  • JOB_DESTRUCTION_CONTINUERS - Job destruction from contracting establishments

  • JOB_DESTRUCTION_RATE - Job destruction rate (as percentage)

Example queries:

  • "What were the job creation and destruction rates for California in 2023?"

  • "Show me firm startups and shutdowns by state for 2022"

  • "Get establishment births and deaths for professional services (NAICS 54) for all states in 2023"

  • "Compare business dynamics between metropolitan and non-metropolitan areas in Texas for 2022"

  • "What is the net job creation in young firms (0-5 years old) for all states in 2023?"

  • "Show me job creation rates by establishment size in New York for 2022"

  • "Get business dynamics statistics for the tech sector (NAICS 51, 54, 55) by state for 2023"

  • "What's the startup rate and job creation from new firms in Florida metro areas for 2022?"

Perfect for: Business environment analysis, economic vitality assessment, entrepreneurship research, job market dynamics, evaluating economic health when considering relocation.

Find more info: BDS Documentation

Example Prompts

Try these prompts with Claude Desktop after setup:

Demographics & Population

  • "What is the total population of California in 2020?"

  • "Get the current 2023 population estimates for all states"

  • "Show me median household income for all states in 2022"

  • "What's the Hispanic population in Texas counties in 2020?"

  • "Get population by age and sex for New York state"

Housing & Economic Data

  • "What is the median home value in San Francisco (state 06, county 075)?"

  • "Compare unemployment rates across all U.S. states"

  • "Show me median household income for all states"

  • "Get property configuration data for rental housing in 2021"

  • "Show me rental housing expenses for properties with 5-24 units"

  • "What are the financing characteristics of rental properties?"

Poverty & Income

  • "What is the poverty rate in California?"

  • "Show me child poverty rates for all counties in Mississippi"

  • "Get poverty statistics and median income for all states"

  • "Compare poverty rates across states"

  • "What percent of school-age children are in poverty in Texas?"

  • "Show me poverty data for counties in Florida"

Business Statistics

  • "How many restaurants (NAICS 72) are in California?"

  • "Get employment and payroll for tech companies (NAICS 541) by state"

  • "Show me retail establishments in New York state"

  • "What's the total employment in professional services in 2022?"

  • "Get Economic Census data for manufacturing (NAICS 31-33) by state"

Comparisons & Analysis

  • "Compare population growth across states from 2020 to 2023"

  • "Show me the difference between 2020 census and 2023 population estimates for California"

  • "Compare business establishments across states in accommodation and food services"

Geocoding & Geography

  • "What Census tract is 1600 Pennsylvania Avenue NW, Washington DC in?"

  • "Geocode 350 Fifth Avenue, New York, NY and tell me what county it's in"

  • "What geographies contain coordinates 37.7749, -122.4194?"

  • "Get the boundary polygon for California as GeoJSON"

  • "Show me the geographic boundaries for all counties in Texas"

  • "Get the Census tract boundaries for San Francisco County"

  • "What is the land area of Texas?"

  • "Show me the geographic metadata for all states including land and water area"

  • "Get the centroid coordinates for Los Angeles County"

Health & Social Services

  • "What percent of people in California have health insurance?"

  • "Show me uninsured rates for all counties in Texas"

  • "Get health insurance coverage for people under 65 in Florida"

  • "Compare health insurance rates across states for low-income populations"

  • "What is the uninsured rate for children in Arizona?"

Government & Public Sector

  • "How many state government employees does California have?"

  • "Show me total government employment and payroll by state"

  • "What is local government employment in Texas?"

  • "Compare state vs local government employees across all states"

  • "Get full-time and part-time government employment for New York"

Business Ownership & Demographics

  • "How many businesses are owned by women in California?"

  • "Get employer firms and employees for Hispanic-owned businesses by state"

  • "Show me veteran-owned business statistics for all states"

  • "What are the receipts for Asian-owned businesses in San Francisco County?"

  • "Compare business ownership by demographic groups across states"

  • "How many employees work at Black-owned businesses in Texas?"

Community Resilience & Neighborhood Risk

  • "What is the social vulnerability for all tracts in San Francisco County?"

  • "Show me community resilience estimates for California counties"

  • "Get neighborhood-level vulnerability data for census tracts in Los Angeles"

  • "Which neighborhoods have the highest disaster vulnerability?"

  • "Compare resilience scores across states"

  • "Show me the percent of people with 3+ vulnerability factors by tract"

  • "What neighborhoods are most prepared for disasters?"

International / Global Demographics

  • "What is the current population of China?"

  • "Show me life expectancy trends for India from 2000 to 2024"

  • "Compare birth rates and death rates across all countries in 2024"

  • "What are the population projections for Brazil through 2050?"

  • "Get fertility rates for all African countries"

  • "Show me median age and population density for European countries"

  • "What countries have the highest infant mortality rates?"

Employment & Job Market (Quarterly Workforce Indicators)

  • "What are the employment levels and average earnings in San Francisco County for Q1 2024?"

  • "Show me job creation rates for all states in Q4 2023"

  • "Get hiring and separation rates for professional services by state for Q2 2024"

  • "Compare average earnings between male and female workers in California for Q3 2023"

  • "What are the turnover rates by age group in New York metro areas?"

  • "Show me employment by education level for all counties in Texas for Q2 2024"

  • "Get job creation in young firms (0-1 years) for California for Q1 2024"

  • "What are the wage trends for tech workers in Seattle metro area?"

Business Dynamics & Economic Vitality

  • "What were the job creation and destruction rates for California in 2023?"

  • "Show me firm startups and shutdowns by state for 2023"

  • "Get establishment births and deaths for professional services for all states in 2023"

  • "Compare business dynamics between metro and non-metro areas in Texas for 2023"

  • "What is the net job creation in young firms (0-5 years old) for all states in 2023?"

  • "Show me job creation rates by establishment size in New York for 2023"

  • "Get business dynamics for the tech sector by state for 2023"

  • "What's the startup rate in Florida metro areas for 2023?"

Development

Setup

git clone https://github.com/mattpodwysocki/census-mcp-server.git
cd census-mcp-server
npm install
cp .env.example .env
# Edit .env and add your CENSUS_API_KEY

Build

npm run build

Inspect Server

npm run inspect:dev

Testing

Run the unit test suite:

npm test

Run tests with coverage report:

npm run test:coverage

Run tests in watch mode:

npm run test:watch

API Reference

The Census API provides access to numerous datasets. This MCP server currently supports:

  • American Community Survey (ACS) - 1-year and 5-year estimates

  • Decennial Census - 2020, 2010 complete counts

  • Population Estimates Program (PEP) - Annual estimates

  • County Business Patterns (CBP) - Annual business statistics

  • Economic Census - Comprehensive business data (every 5 years)

  • Geographic Information API - Geographic metadata (land area, water area, coordinates)

  • Census Geocoding Services - Address to coordinates, reverse geocoding (no API key)

  • TIGERweb GeoServices - Geographic boundaries as GeoJSON (no API key)

  • Small Area Health Insurance Estimates (SAHIE) - Health insurance coverage by county

  • Annual Survey of Public Employment & Payroll - Government employment and payroll

  • Small Area Income and Poverty Estimates (SAIPE) - Poverty estimates and median income

  • Rental Housing Finance Survey (RHFS) - Rental property financial and mortgage characteristics

  • Annual Business Survey (ABS) - Business ownership by demographics (replaced SBO)

  • Community Resilience Estimates (CRE) - Social vulnerability and disaster resilience

  • International Database (IDB) - Global population estimates and projections (1950-2100)

Geographic Identifiers

State FIPS Codes

States are identified by 2-digit FIPS codes:

  • 01 - Alabama

  • 06 - California

  • 12 - Florida

  • 36 - New York

  • 48 - Texas

Full list: State FIPS Codes

County FIPS Codes

Counties are identified by 3-digit codes within each state.

NAICS Industry Codes

Industries are classified using the North American Industry Classification System (NAICS):

  • 2-digit: Sector (e.g., "72" = Accommodation and Food Services)

  • 3-digit: Subsector (e.g., "721" = Accommodation)

  • 4-digit: Industry Group (e.g., "7211" = Traveler Accommodation)

  • 6-digit: Industry (e.g., "721110" = Hotels and Motels)

Full list: NAICS Codes

Data Usage & Privacy

What data is sent to Census APIs

When you use the MCP server tools, the following data is sent to Census Bureau APIs:

  • API key

  • Query parameters (year, variables, geography)

  • Geographic identifiers (state, county codes)

  • Industry codes (NAICS)

Your privacy

  • Local execution: All API calls are made directly from your environment to Census APIs

  • API key security: Your Census API key remains on your local machine

  • No data storage: This MCP server does not store, log, or collect any of your data

  • Direct communication: No intermediary server between you and Census APIs

Third-party data usage

  • Census Bureau's privacy policy: Privacy Policy

  • API terms: Standard Census API terms apply to all requests

Contributing

We welcome contributions! Here's how you can help:

  1. Fork the repository

  2. Create a feature branch: git checkout -b feature/your-feature-name

  3. Make your changes and add tests

  4. Run the test suite: npm test

  5. Lint your code: npm run lint:fix

  6. Commit your changes: git commit -m "Add your feature"

  7. Push to your fork: git push origin feature/your-feature-name

  8. Open a Pull Request

Development Guidelines

  • Add unit tests for new features

  • Update README documentation for new tools

  • Follow existing code style and patterns

  • Run npm run lint and npm test before committing

  • Write clear commit messages

Ideas for Contributions

  • Add more Census datasets and tools

  • Improve error handling and validation

  • Add more comprehensive examples

  • Improve documentation

  • Report bugs and suggest features

Support

License

MIT License - see LICENSE for details

Resources

Available Tools

17 tools
acs_data_toolACS Data ToolA
Read-onlyIdempotent

Retrieve demographic and economic data from the American Community Survey (ACS). Use this to get population statistics, household income, employment, education, housing data, and more. Supports both 1-year and 5-year estimates at various geographic levels.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearYesYear for ACS data (e.g., 2022). Use the most recent year available.
datasetNoACS dataset: "acs1" (1-year estimates, more current but less detailed) or "acs5" (5-year estimates, more detailed and stable)acs5
variablesYesCensus variable codes to retrieve (e.g., ["B01001_001E", "B19013_001E"]). B01001_001E is total population, B19013_001E is median household income.
geographyNoGeographic level for data aggregationstate
stateNoState FIPS code (required for county, tract, place geographies)
countyNoCounty FIPS code (required for tract geography)

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, etc., so the description doesn't need much. It adds that it supports 1-year and 5-year estimates, which is useful context.

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?

Two sentences, front-loaded with purpose, no wasted words. Highly concise and effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 params, no output schema, the description covers the main purpose and options. Could mention return format but adequate for a data retrieval tool.

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

Parameters4/5

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

Schema coverage is 100% with descriptions. The description adds context about dataset and geography options, and example variable codes, providing additional meaning.

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 clearly states it retrieves demographic and economic data from the ACS, listing specific data types and estimate types. This distinguishes it from siblings like decennial_census_tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'Use this to get...' which is clear, but it doesn't explicitly mention when not to use it or compare to alternatives, missing some guidance.

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

annual_business_survey_toolAnnual Business Survey ToolA
Read-onlyIdempotent

Retrieve business ownership data from the Annual Business Survey (ABS). Get comprehensive business statistics by owner demographics including sex, ethnicity, race, and veteran status. Data includes number of employer firms, employees, annual payroll, and receipts. The ABS replaced the Survey of Business Owners (SBO) and provides annual data from 2017 to present. Useful for analyzing business ownership patterns, diversity in entrepreneurship, and economic contributions by demographic groups.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNoYear for business survey data (2017-2023). Default: 2023.2023
variablesNoArray of business variables to retrieve. Common: FIRMPDEMP (employer firms), EMP (employees), PAYANN (annual payroll), RCPPDEMP (receipts/sales), FIRMPDEMP_PCT (percent of employer firms), EMP_PCT (percent of employees). Default: [FIRMPDEMP, EMP, PAYANN, RCPPDEMP].
geographyYesGeographic level to query. Options: us (national), state, county, metro area.
stateNoState FIPS code (2 digits). Required for county geography, optional for state geography to get a specific state.
countyNoCounty FIPS code (3 digits). Optional to get a specific county within a state.
sexNoSex of owner. 001: All (default), 002: Male, 003: Female.001
ethnicityNoEthnicity of owner. 001: All (default), 002: Hispanic, 003: Non-Hispanic.001
raceNoRace of owner. 00: All (default), 10: White, 20: Black or African American, 30: American Indian and Alaska Native, 40: Asian, 50: Native Hawaiian and Other Pacific Islander, 60: Two or more races.00
veteranNoVeteran status of owner. 001: All (default), 002: Veteran, 003: Non-veteran.001

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior. The description adds context about the survey replacing the SBO and annual data availability (2017-present), which is consistent. It does not mention response size, rate limits, or pagination, but for a read-only tool with thorough annotations, this level of additional transparency is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is a concise three-sentence paragraph that front-loads the main verb 'Retrieve' and efficiently covers source, data types, demographics, and temporal scope. It avoids redundancy and earns each sentence's place, though breaking into sub-topics could improve scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 9 parameters, no output schema, and moderate complexity, the description covers the tool's purpose, data source, and key demographics but lacks specifics on output format (e.g., JSON structure, pagination) or handling of multiple variables. It meets basic needs but leaves gaps in understanding the exact result shape.

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?

Schema coverage is 100%, so the baseline is 3. The description adds overarching context about the survey and demographics but does not explain parameter syntax or relationships beyond what the schema already provides. It reiterates variable names and owner demographics, which aligns with schema descriptions but adds minimal new semantic value.

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 clearly states it retrieves business ownership data from the Annual Business Survey (ABS), specifies demographics (sex, ethnicity, race, veteran status), and lists data types (employer firms, employees, payroll, receipts). It distinguishes from the replaced SBO and provides temporal context (2017-present), effectively differentiating it from sibling tools like county_business_patterns_tool or economic_census_tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions it is 'useful for analyzing business ownership patterns, diversity in entrepreneurship, and economic contributions by demographic groups,' implying usage context. However, it lacks explicit guidance on when not to use it or alternatives among siblings, leaving the agent to infer usage boundaries without clear exclusion criteria.

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

business_dynamics_statistics_toolBusiness Dynamics Statistics ToolA
Read-onlyIdempotent

Retrieve annual business dynamics statistics (BDS) showing job creation, job destruction, establishment births/deaths, and firm startups/shutdowns. Track economic dynamism and business health from 1978-2023 at national, state, and metro/micro area levels. Filter by industry (NAICS), firm age, firm size, establishment age, and establishment size. Essential for understanding business environment, entrepreneurship rates, and economic vitality when evaluating areas.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearYesYear for BDS data (1978-2023)
variablesNoVariables to retrieve. Common: ESTABS (establishments), ESTABS_ENTRY (new establishments), ESTABS_EXIT (closing establishments), JOB_CREATION (gross jobs created), JOB_DESTRUCTION (gross jobs destroyed), NET_JOB_CREATION (net job change), FIRMS (number of firms), FIRMS_ENTRY (new firms), FIRMS_EXIT (closing firms), EMP (employment), DENOM (denominator for rates), JOB_CREATION_BIRTHS (job creation from births), JOB_CREATION_CONTINUERS (job creation from expanding firms), JOB_CREATION_RATE (job creation rate), JOB_DESTRUCTION_DEATHS (job destruction from deaths), JOB_DESTRUCTION_CONTINUERS (job destruction from contracting firms), JOB_DESTRUCTION_RATE (job destruction rate)
geographyNoGeographic level: us (national), state (state), metro (metropolitan/micropolitan statistical area)state
stateNoState FIPS code (required for metro geography, optional for state)
naicsNoNAICS 2012 industry code. Examples: "00" (all), "11" (agriculture), "23" (construction), "31-33" (manufacturing), "42" (wholesale trade), "44-45" (retail trade), "51" (information), "52" (finance), "53" (real estate), "54" (professional services), "55" (management), "56" (administrative), "61" (educational), "62" (healthcare), "71" (arts/entertainment), "72" (accommodation/food), "81" (other services)
metroNoMetro filter: 0 (all), 1 (filter applied), M (metropolitan), N (micropolitan/non-metro)
geocompNoGeographic component: A0 (all), C1 (Metro/Micro Central County), O1 (Metro/Micro Outlying County)
sicNoSIC code flag: 0 (NAICS), 1 (SIC 1987)
fage4NoFirm age: a) 0 (startups), b) 1-5, c) 6-10, d) 11-15, e) 16-20, f) 21-25, g) 26+, h) Left Censored
fsizeNoFirm size by employment: a) 1-4, b) 5-9, c) 10-19, d) 20-49, e) 50-99, f) 100-249, g) 250-499, h) 500-999, i) 1000-2499, j) 2500-4999, k) 5000-9999, l) 10000+
eage4NoEstablishment age: a) 0 (new), b) 1-5, c) 6-10, d) 11-15, e) 16-20, f) 21-25, g) 26+, h) Born before 1976, i) Left Censored
esizeNoEstablishment size by employment: a) 1-4, b) 5-9, c) 10-19, d) 20-49, e) 50-99, f) 100-249, g) 250-499, h) 500-999, i) 1000-2499, j) 2500+

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by specifying the data scope (annual, national/state/metro, filters) and the fact that it retrieves historical data from 1978-2023. No contradictions, and it provides context beyond 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?

Two sentences, front-loaded with the key action and resource. Every sentence adds value: first sentence defines the tool, second explains filters and use case. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 12 parameters and no output schema, the description adequately covers the data types, time range, geography, and filters. It also states the tool's essential use. It could mention the return format or behavior when no variables are specified (schema has defaults), but overall it is complete enough for effective tool selection.

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?

Schema description coverage is 100%, so baseline is 3. The description mentions filtering by NAICS, firm age, etc., but these are already detailed in the input schema. No additional semantic information about parameters is provided beyond what the schema offers.

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 clearly states the verb 'Retrieve' and resource 'annual business dynamics statistics (BDS)', lists specific data types (job creation, destruction, births/deaths) and specifies the data source (BDS) and time range (1978-2023). This distinguishes it from sibling tools like annual_business_survey_tool or county_business_patterns_tool, which cover different datasets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for economic analysis ('essential for understanding business environment, entrepreneurship rates, and economic vitality') but does not explicitly state when not to use this tool or compare it to alternatives. No exclusions or alternative tool names are mentioned.

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

community_resilience_toolCommunity Resilience Estimates ToolA
Read-onlyIdempotent

Retrieve community resilience and social vulnerability data from the Community Resilience Estimates (CRE). Track how socially vulnerable every neighborhood is to disaster impacts. Data includes rates and counts of individuals with zero, one-two, or three-plus components of social vulnerability (disability, single-parent households, limited English, poverty, no vehicle, crowded housing, group quarters, age vulnerability). Perfect for neighborhood-level analysis, disaster preparedness assessment, and real estate applications. Available at tract level for detailed neighborhood insights.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNoYear for community resilience estimates. Available years: 2019, 2021, 2022, 2023. Default: 2023.2023
variablesNoArray of resilience variables to retrieve. Common: PRED0_PE (% with zero vulnerability factors), PRED12_PE (% with 1-2 factors), PRED3_PE (% with 3+ factors), PRED0_E (count with zero factors), PRED12_E (count with 1-2 factors), PRED3_E (count with 3+ factors), POPUNI (population universe). Default: [PRED0_PE, PRED12_PE, PRED3_PE, POPUNI].
geographyYesGeographic level to query. Options: us (national), state, county, tract. Tract level provides neighborhood-level detail.
stateNoState FIPS code (2 digits). Required for county and tract geographies, optional for state geography to get a specific state.
countyNoCounty FIPS code (3 digits). Required for tract geography, optional to get a specific county.

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds context about the data's nature (tracking vulnerability) but does not disclose additional behavioral traits such as rate limits or authentication requirements. With annotations covering safety profile, a score of 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is mostly concise with five sentences, front-loading the purpose. Some redundancy exists (e.g., 'neighborhood-level' mentioned twice), but overall it is efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters, no output schema, and annotations, the description adequately explains the data source, use cases, geographic levels, and variable types. It does not cover output format, but that is reasonable for a read-only data retrieval tool without output schema.

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?

Schema coverage is 100%, so the schema already documents all parameters. The description mentions data components (rates, counts) but does not add significant meaning beyond what the schema provides for each parameter. Baseline 3 is suitable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as retrieving community resilience and social vulnerability data from CRE. It specifies the data includes rates and counts of vulnerability components. While it distinguishes from siblings by emphasizing neighborhood-level analysis and disaster preparedness, it does not explicitly differentiate from similar tools like poverty_statistics_tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for neighborhood-level analysis, disaster preparedness, and real estate applications, but does not provide explicit guidance on when to use versus alternatives or when not to use. No mention of prerequisites or exclusions.

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

county_business_patterns_toolCounty Business Patterns ToolA
Read-onlyIdempotent

Retrieve business statistics from County Business Patterns (CBP). Get establishment counts, employment, payroll data by industry (NAICS code), geography, and business size. Provides annual data on the number and types of businesses operating in the U.S.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNoYear for CBP data (1986-present, most recent is typically 2 years behind)
variablesNoVariables to retrieve. Common: ESTAB (establishments), EMP (employment), PAYANN (annual payroll in $1000s), PAYQTR1 (Q1 payroll), NAICS2017 (industry code)
geographyNoGeographic level for business datastate
stateNoState FIPS code (required for county geography)
naicsNoNAICS 2017 industry code (2-6 digits). Examples: "72" (accommodation/food), "541" (professional services)
employmentSizeClassNoEmployment size code (e.g., "001" for all establishments, "212" for 20-99 employees)

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, confirming safe, idempotent behavior. The description adds value by specifying that the data is annual and covers the number and types of businesses, which informs the agent about the temporal and scope characteristics. 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.

Conciseness5/5

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

Two sentences, no wasted words. The first sentence states the core function and the second adds the data types covered. Information is front-loaded and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately explains the tool's purpose and data elements, but it omits important usage constraints, such as the requirement for a state FIPS code when geography is 'county'. With no output schema, the agent does not know the structure of the response. While the tool is simple, these gaps reduce completeness.

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?

Schema coverage is 100%, with each parameter having a description. The description mentions using NAICS code, geography, and business size, which correspond to parameters, but adds no additional detail beyond what the schema already provides. Therefore, it meets the baseline but does not exceed it.

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 clearly identifies the tool as retrieving County Business Patterns data, a specific government dataset. It states the verb 'Retrieve' and the resource 'business statistics from County Business Patterns', then lists the types of data (establishment counts, employment, payroll) and dimensions (industry, geography, business size). This makes the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like annual_business_survey_tool or economic_census_tool. It does not mention scenarios where CBP is preferred, nor does it caution against misuse. The agent is left to infer appropriateness from the dataset name alone.

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

decennial_census_toolDecennial Census ToolA
Read-onlyIdempotent

Retrieve data from the U.S. Decennial Census (2020, 2010). Get complete population counts, demographics by race/ethnicity, age, sex, and housing unit data. The decennial census provides the most accurate population counts taken every 10 years.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearYesDecennial Census year: "2020" or "2010"
datasetNoDataset: "pl" (redistricting data, default for 2020), "dhc" (demographic and housing), "sf1" (summary file 1, default for 2010)
variablesYesCensus variable codes to retrieve. Common: P1_001N (total pop), P1_003N (White), P1_004N (Black), P2_002N (Hispanic), H1_001N (housing units)
geographyNoGeographic level for data aggregationstate
stateNoState FIPS code (required for county, tract, block group, place)
countyNoCounty FIPS code (required for tract, block group)

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds context about dataset accuracy and decennial frequency, which supplements the annotations without contradiction. It does not detail rate limits or other behaviors, but annotations cover safety adequately.

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 two sentences, front-loading the main purpose exactly. It uses efficient language with no waste, listing key data types and examples.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only data retrieval tool with 6 parameters fully described in the schema and annotations present, the description covers purpose and data types adequately. No output schema is needed for simple retrieval. It is complete enough for the agent to use effectively.

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?

Input schema coverage is 100%, so parameters are well documented with descriptions, enums, and patterns. The description adds common variable codes (e.g., P1_001N) and dataset meanings, but this is marginal beyond the schema. A baseline 3 is appropriate.

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 clearly states the tool retrieves data from the U.S. Decennial Census, specifying the years (2020, 2010) and data types (population counts, demographics, housing units). It implicitly distinguishes from sibling tools like ACS (more frequent) and population estimates (intercensal) by emphasizing decennial census as the most accurate and every-10-years count.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for accurate decennial data but does not explicitly contrast with alternatives like acs_data_tool or population_estimates_tool. No when-to-use or when-not-to-use guidance is provided, leaving comparison to the agent.

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

economic_census_toolEconomic Census ToolA
Read-onlyIdempotent

Retrieve comprehensive business statistics from the Economic Census (conducted every 5 years). Get establishments, employment, sales/receipts, payroll, and value added by industry (NAICS) and geography. The Economic Census is the most detailed source of facts about U.S. business economy.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNoEconomic Census year (conducted every 5 years)2017
variablesNoVariables to retrieve. Common: ESTAB (establishments), EMP (employment), RCPTOT (sales/receipts in $1000s), PAYANN (annual payroll in $1000s), VALADD (value added)
geographyNoGeographic level for economic datastate
stateNoState FIPS code (required for county geography, optional for state)
countyNoCounty FIPS code (required for county geography)
naicsNoNAICS 2017 industry code (2-6 digits). Examples: "54" (professional services), "72" (accommodation/food), "44-45" (retail trade)
sectorNoNAICS sector code (2 digits)

TDQS

A4/5.0
Behavior4/5

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

Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, which the description aligns with and adds context about the tool's comprehensive and detailed scope. No contradictions; description supplements annotations with qualitative claims about being the most detailed source.

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 two sentences, front-loading the core purpose and data types in the first sentence and highlighting significance in the second. Every word adds value with no redundancy or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers what the tool does, what data it returns, and the census periodicity. Given no output schema, it could briefly mention that results are tabular or geo-coded, but overall it is complete enough for a data retrieval tool with no required parameters.

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?

Schema description coverage is 100% with detailed descriptions for each parameter. The tool description adds no semantic information beyond what the schema provides, such as examples of NAICS codes or variable abbreviations already documented in schema 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 clearly states the tool retrieves comprehensive business statistics from the Economic Census (every 5 years), including specific data types like establishments, employment, sales, payroll, and value added. It distinguishes from sibling tools like the annual business survey by emphasizing the census's comprehensive and detailed nature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for detailed business economy facts but does not explicitly state when to use this tool versus alternatives like the annual business survey or county business patterns tool. No direct comparison or exclusion criteria are provided.

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

geocoding_toolCensus Geocoding ToolA
Read-onlyIdempotent

Convert addresses to coordinates or find Census geographies for an address/location. Returns latitude/longitude coordinates and all Census geographic hierarchies (state, county, tract, block, MSA, congressional district, etc.). Supports forward geocoding (address to coordinates) and reverse geocoding (coordinates to geographies). No API key required.

ParametersJSON Schema
NameRequiredDescriptionDefault
searchTypeNoSearch type: "onelineaddress" (single line address), "address" (structured address), "coordinates" (reverse geocoding)onelineaddress
addressNoSingle line address (e.g., "1600 Pennsylvania Avenue NW, Washington, DC 20500"). Required for onelineaddress search.
streetNoStreet address (required for address search)
cityNoCity name
stateNoState (2-letter code or full name)
zipNoZIP code
longitudeNoLongitude (required for coordinates search)
latitudeNoLatitude (required for coordinates search)
returnGeographiesNoReturn geographic hierarchies (state, county, tract, block, MSA, etc.) in addition to coordinates
benchmarkNoBenchmark version (default: Public_AR_Current for current data)Public_AR_Current
vintageNoGeography vintage (default: Current_Current for current boundaries). Only used when returnGeographies is true.Current_Current

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already indicate read-only, idempotent, and open-world behavior. The description adds context by noting no API key required and detailing the output (coordinates and geographic hierarchies). No contradictions.

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 concise, front-loaded with the main purpose, and every sentence adds essential information without fluff.

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?

Given the high schema coverage, existence of an output schema, and rich annotations, the description adequately covers the tool's functionality, including both geocoding modes and the return of geographic hierarchies.

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 covers all parameters with descriptions (100% coverage). The description adds value by explaining the two search types but does not significantly expand on parameter meaning beyond the schema.

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 clearly states the tool converts addresses to coordinates or finds Census geographies, and specifies forward and reverse geocoding. It distinguishes itself from sibling tools by emphasizing Census geographic hierarchies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the two search types and notes that no API key is required. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions.

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

geoinfo_toolGeographic Information ToolA
Read-onlyIdempotent

Retrieve geographic metadata and reference information from the Census Bureau Geographic Information API. Get land area, water area, internal point coordinates (centroid), and FIPS codes for geographic entities. Useful for geographic reference data, area calculations, and mapping coordinates.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNoVintage year for geographic data (2020-present). Default: 2023.2023
variablesNoArray of geographic variables to retrieve. Common: NAME, AREALAND, AREALAND_SQMI, AREAWATR, AREAWATR_SQMI, INTPTLAT, INTPTLON. Default: all available.
geographyYesGeographic level to query. Options: us, state, county, tract, place, congressional district.
stateNoState FIPS code (2 digits). Required for county, tract, place, and congressional district geographies.
countyNoCounty FIPS code (3 digits). Required for tract geography.

TDQS

A4/5.0
Behavior4/5

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

Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds specific data types returned (land area, water area, etc.) and specifies the API source, providing value beyond annotations. No contradictory statements.

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 three sentences, front-loaded with the main action and data types. Each sentence adds value without fluff, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose, data outputs, and use cases. However, with no output schema, it does not specify the return format (e.g., JSON structure). It also does not explicitly mention parameter dependencies (e.g., state required for county) though the schema covers this. Overall, it is mostly complete but slightly lacking in return format details.

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?

Schema description coverage is 100%, so the baseline is 3. The description lists common variable examples but does not add substantial meaning beyond the schema's parameter descriptions. No new insights on parameter interactions or constraints.

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 clearly states the tool retrieves geographic metadata from the Census Bureau Geographic Information API, listing specific data types (land area, water area, centroid coordinates, FIPS codes) and use cases. This distinguishes it from sibling tools that provide survey data or geocoding services.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions usefulness for 'geographic reference data, area calculations, and mapping coordinates' but does not explicitly contrast with sibling tools like geocoding_tool or tigerweb_tool, nor provide when-to-use or when-not-to-use guidance. The usage context is implied but not clarified.

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

health_insurance_toolHealth Insurance Estimates ToolA
Read-onlyIdempotent

Retrieve health insurance coverage estimates from the Small Area Health Insurance Estimates (SAHIE) program. Get single-year estimates of health insurance coverage status for all counties by selected economic and demographic characteristics. Data includes number and percentage of people with and without health insurance, by age group, income level, and race/ethnicity. Available from 2006 to present.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNoYear for health insurance estimates (2006-2023). Default: 2022.2022
variablesNoArray of health insurance variables to retrieve. Common: NIC_PT (number insured), NUI_PT (number uninsured), PCTIC_PT (percent insured), PCTUI_PT (percent uninsured), NIPR_PT (number in poverty range), PCTLIIC_PT (percent low-income insured). Default: [NIC_PT, NUI_PT, PCTIC_PT, PCTUI_PT].
geographyYesGeographic level to query. Options: us (national), state, county.
stateNoState FIPS code (2 digits). Required for county geography, optional for state geography to get a specific state.
countyNoCounty FIPS code (3 digits). Optional to get a specific county within a state.
ageCategoryNoAge category filter. 0: Under 65 years, 1: 18 to 64, 2: 40 to 64, 3: 50 to 64, 4: Under 19 years, 5: 21 to 64 years.
incomeRangeNoIncome range category. 0: All incomes, 1: At or below 138% of poverty threshold, 2: At or below 200%, 3: At or below 250%, 4: At or below 400%.
raceEthnicityNoRace/ethnicity category. 0: All races, 1: White alone not Hispanic, 2: Black alone, 3: Hispanic (any race).

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds behavioral context by stating it retrieves single-year estimates and availability from 2006 to present, which complements the annotations effectively.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Three sentences, front-loaded with the main purpose and key details. Efficient but could be slightly more concise without losing value. No unnecessary repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 8 parameters (1 required, 4 enums) and no output schema, the description provides a reasonable overview of data content, dimensions, and year range. It does not explain return format or geography selection details, but the schema handles parameter choices adequately.

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?

All 8 parameters have descriptions in the input schema (100% coverage). The tool description only mentions categories (age, income, race) without adding new semantic details beyond the schema. Baseline score of 3 applies as schema carries the load.

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 clearly states the tool retrieves health insurance coverage estimates from the SAHIE program, specifying data types (number/percentage insured/uninsured) and dimensions (age, income, race/ethnicity). This clearly differentiates it from sibling tools like poverty_statistics_tool or population_estimates_tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for health insurance estimates but does not explicitly state when to use it versus alternatives. No exclusion criteria or comparison with sibling tools are provided, leaving the agent to infer usage context.

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

international_database_toolInternational Database ToolA
Read-onlyIdempotent

Retrieve global population statistics from the U.S. Census Bureau International Database (IDB). Access population estimates and projections for 200+ countries worldwide from 1950 to 2100. Data includes total population, birth rates, death rates, life expectancy, fertility rates, age distributions, migration, and more. Perfect for international demographic analysis, global population trends, and country comparisons.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearYesYear for population data (1950-2100). Historical data 1950-present, projections to 2100.
variablesYesArray of IDB variable codes to retrieve. Common: POP (total population), AREA_KM2 (land area), CBR (crude birth rate), CDR (crude death rate), E0 (life expectancy), GR (growth rate), IMR (infant mortality rate), MAB (median age), TFR (total fertility rate), NI (natural increase), NM (net migration), POP_DENS (population density).
countryNoFIPS country code (e.g., "CH" for China, "IN" for India, "US" for United States). If not specified, returns data for all countries.
ageGroupNoAge group for age-specific queries (e.g., "0-4", "5-9", "10-14", etc.). Use with age-specific variables.
sexNoSex filter: 0 = Both sexes, 1 = Male, 2 = Female. Default: 0.

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds context about the source and time range but does not introduce additional behavioral traits 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.

Conciseness5/5

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

The description is concise, well-structured, and front-loaded with the core purpose. It uses only a few sentences to convey the tool's scope and capabilities without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although there is no output schema, the description lists the types of data returned (e.g., total population, birth rates). It adequately covers the tool's scope and parameter usage, but could mention return format or example response.

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?

All 5 parameters have descriptions in the input schema (100% coverage), so the description does not add significant semantics beyond the schema. The description mentions data types but not parameter-specific details.

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 clearly states the tool retrieves global population statistics from the U.S. Census Bureau International Database, covering 200+ countries from 1950-2100, and lists specific data types. It distinguishes itself from sibling tools that are primarily US-focused.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for international demographic analysis but does not explicitly state when not to use or provide alternatives. The sibling context suggests it's for non-US data, but no direct guidance.

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

population_estimates_toolPopulation Estimates ToolA
Read-onlyIdempotent

Retrieve annual population estimates from the Population Estimates Program (PEP). Get current population counts by age, sex, race, and Hispanic origin. Updated annually with the most recent population estimates between decennial censuses.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNoVintage year for population estimates (2020-present, default: 2023)
variablesNoVariables to retrieve. Common: POP (population estimate), AGE (age group), SEX (sex code), POPGROUP (race/ethnicity), HISP (Hispanic origin)
geographyNoGeographic level for population estimatesstate
stateNoState FIPS code (required for county geography)
ageGroupNoAge group code (e.g., "0" for all ages, "1" for 0-4 years)
sexNoSex code: "0" (both sexes), "1" (male), "2" (female)
hispanicOriginNoHispanic origin: "0" (both), "1" (non-Hispanic), "2" (Hispanic)

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds context about the data source (PEP) and update frequency, which goes beyond annotations without contradiction.

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?

Two sentences, front-loaded with purpose, no redundant words. Every sentence adds value. Excellent for an AI agent to quickly grasp.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description does not detail return structure or default behavior when no parameters are provided. With 7 optional parameters, more guidance (e.g., 'If no geography specified, defaults to state') would improve completeness.

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?

Schema coverage is 100% with descriptions for all 7 parameters. The description lists demographic categories (age, sex, race, Hispanic origin) that map to parameters but does not add new meaning beyond the schema. Baseline score of 3 is appropriate.

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 clearly states the tool retrieves annual population estimates from PEP with demographic breakdowns by age, sex, race, and Hispanic origin. It distinguishes from siblings like decennial_census_tool (decennial vs annual) and acs_data_tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions 'updated annually' and 'between decennial censuses', implying when to use, but no explicit when-not-to-use or comparison to sibling tools. Guidance is implicit but insufficient.

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

poverty_statistics_toolPoverty Statistics ToolA
Read-onlyIdempotent

Retrieve poverty estimates and median household income from the Small Area Income and Poverty Estimates (SAIPE) program. Get single-year estimates of people in poverty by age groups for states and counties. Data includes poverty counts, poverty rates, and median household income. The only source of data for single-year estimates of poverty for all U.S. counties. Available from 1989 to present.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNoYear for poverty estimates (1989-2022). Default: 2022.2022
variablesNoArray of poverty/income variables to retrieve. Common: SAEPOVALL_PT (poverty count), SAEPOVRTALL_PT (poverty rate %), SAEPOV0_17_PT (children 0-17 in poverty), SAEPOV5_17R_PT (school-age 5-17 in poverty), SAEPOV0_4_PT (children 0-4 in poverty), SAEMHI_PT (median household income). Default: [SAEPOVALL_PT, SAEPOVRTALL_PT, SAEMHI_PT].
geographyYesGeographic level to query. Options: us (national), state, county.
stateNoState FIPS code (2 digits). Required for county geography, optional for state geography to get a specific state.
countyNoCounty FIPS code (3 digits). Optional to get a specific county within a state.

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by specifying the data source (SAIPE), temporal coverage (1989-present), and data types (counts, rates, income). It does not contradict annotations and provides useful behavioral context beyond the metadata, though it omits details like rate limits or pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is four sentences, front-loaded with the core purpose. It efficiently covers source, scope, data types, uniqueness, and availability. While the last two sentences could be combined, the overall structure is clear and concise without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description adequately covers what data is returned (poverty counts, rates, median income, age groups) and geographic granularity (states, counties). It also mentions the time range and uniqueness. The multiple parameters (5) are mostly explained via the schema, and the description provides enough context for an agent to understand the tool's purpose. A perfect score would require a brief note on output format or pagination, but the current description is sufficient.

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?

Schema description coverage is 100%, so the baseline is 3. The description lists some variable names (e.g., SAEPOVALL_PT) and mentions age groups, but this largely repeats the schema's parameter descriptions. It does not add significant new meaning beyond what the schema already provides, so the score aligns with the baseline.

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 clearly states the verb 'Retrieve', the resource 'poverty estimates and median household income from the SAIPE program', and the scope (single-year, states/counties, age groups, counts/rates/income). It also highlights its uniqueness as the only source for single-year county poverty estimates, distinguishing it from sibling tools like acs_data_tool or population_estimates_tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use (need poverty/income data from SAIPE) and emphasizes its unique coverage, but does not explicitly state when not to use or provide alternatives. The mention of being the 'only source for single-year estimates of poverty for all U.S. counties' gives implicit guidance, but without exclusions the score is slightly below a top 5.

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

public_sector_toolPublic Sector Employment ToolA
Read-onlyIdempotent

Retrieve government employment and payroll statistics from the Annual Survey of Public Employment & Payroll. Get employment counts and payroll data for state and local governments. Data includes full-time and part-time employees, total hours worked, and payroll amounts. Supports filtering by government type (state, local, or combined). Available from 2017 to present.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNoYear for public sector employment data (2017-2024). Default: 2024.2024
variablesNoArray of employment/payroll variables to retrieve. Common: TOT_EMP (total employment), FT_EMP (full-time), PT_EMP (part-time), TOT_PAY (total payroll), FT_PAY (full-time payroll), PT_PAY (part-time payroll), TOT_HRS (total hours). Default: [TOT_EMP, FT_EMP, PT_EMP, TOT_PAY].
geographyYesGeographic level to query. Options: us (national), state (all states or specific state).
stateNoState FIPS code (2 digits). Optional to get data for a specific state.
governmentTypeNoType of government. state: state government only, local: local government only, combined: state and local combined. If not specified, returns all types.

TDQS

A4/5.0
Behavior4/5

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

Annotations already convey readOnly, destructive, idempotent, and openWorld hints. The description adds valuable behavioral context: data source, year range (2017-present), and supported government types. This adds clarity beyond the 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 a focused 4-sentence paragraph that front-loads the purpose and efficiently covers data types, filtering, and availability. No superfluous content; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers data scope, filtering, and time range. It lacks details on output structure (since no output schema), which is a minor gap. However, for a read-only tool with well-documented inputs, it is nearly complete.

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?

Schema coverage is 100%, so the schema already describes parameters thoroughly. The description adds an overview and common variable examples but does not significantly enhance understanding beyond the schema. Baseline 3 is appropriate.

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 clearly states the tool retrieves government employment and payroll statistics from the Annual Survey of Public Employment & Payroll, specifying the data types (full-time/part-time, hours, payroll) and filtering options. It distinguishes itself from siblings by naming the exact survey and focusing on public sector data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context for typical use (public employment data) but does not explicitly contrast with sibling tools or explain when to avoid using it. No alternatives are mentioned, leaving the agent to infer use cases from the survey name.

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

quarterly_workforce_indicators_toolQuarterly Workforce Indicators ToolA
Read-onlyIdempotent

Retrieve quarterly employment statistics from the Quarterly Workforce Indicators (QWI) program. Access 32+ economic indicators including employment levels, job creation/destruction, hires, separations, earnings, and turnover rates. Data available by worker demographics (age, sex, education, race/ethnicity), industry (NAICS), and firm characteristics (age, size). Covers 1990-present at state, county, metro area, and workforce investment board area levels. Essential for analyzing local job markets, wage trends, and employment dynamics.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearYesYear for QWI data (1990-present)
quarterYesQuarter (1-4)
variablesNoVariables to retrieve. Common: Emp (employment), EmpS (stable employment), HirA (hires), Sep (separations), EarnS (average earnings), EarnBeg (beginning-of-quarter earnings), EarnHirAS (average earnings of hires), Payroll (total payroll), TurnOvrS (turnover rate), HirAS (hire rate), SepS (separation rate), JC (job creation), JD (job destruction), JobChngH (net job change from hires), JobChngS (net job change from separations)
geographyNoGeographic level: state (state), county (county), metro (metropolitan area), wib (workforce investment board area)state
stateNoState FIPS code (required for county geography)
sexNoSex: 0 (both), 1 (male), 2 (female)
agegrpNoAge group: A00 (all), A01 (14-18), A02 (19-21), A03 (22-24), A04 (25-34), A05 (35-44), A06 (45-54), A07 (55-64), A08 (65-99)
educationNoEducation: E0 (all), E1 (less than high school), E2 (high school), E3 (some college), E4 (bachelor or advanced), E5 (advanced degree)
raceNoRace: A0 (all), A1 (White), A2 (Black), A3 (American Indian/Alaska Native), A4 (Asian), A5 (Native Hawaiian/Pacific Islander), A6 (Two or more races), A7 (not specified), A8 (Asian and Native Hawaiian/Pacific Islander combined)
ethnicityNoEthnicity: A0 (all), A1 (not Hispanic), A2 (Hispanic)
industryNoNAICS 2012 industry code (2-4 digits). Examples: "00" (all), "11" (agriculture), "23" (construction), "31-33" (manufacturing), "54" (professional services), "62" (healthcare)
firmageNoFirm age: 0 (all), 1 (0-1 years), 2 (2-3 years), 3 (4-5 years), 4 (6-10 years), 5 (11+ years)
firmsizeNoFirm size: 0 (all), 1 (0-19 employees), 2 (20-49), 3 (50-249), 4 (250-499), 5 (500+)

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint: true and idempotentHint: true, so the description need not reiterate safety. It adds value by specifying the time range (1990-present), geographic levels, and demographic breakdowns. There is 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 description is a single paragraph of four sentences, efficiently covering the key aspects: what statistics are available, dimensions, geographic scope, and purpose. No wasted words; it is well-front-loaded and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks information about the output format (e.g., JSON, CSV) or structure, which is important for a data retrieval tool. However, the input schema is fully documented, and annotations cover safety. Given no output schema, the description could be more complete by specifying return format.

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

Parameters4/5

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

Schema description coverage is 100%, so each parameter already has a description. The tool description adds value by explaining the meaning of common variables (e.g., 'Emp' for employment) and providing industry examples (e.g., '23' for construction). This enriches understanding beyond the schema.

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 clearly states the tool's purpose: to retrieve quarterly employment statistics from the QWI program. It lists over 32 economic indicators and specifies dimensions like demographics, industry, and geography. The tool name and title are distinct, and the description differentiates it from sibling tools by focusing on QWI-specific data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives. It mentions 'Essential for analyzing local job markets' but provides no direct comparison with sibling tools like acs_data_tool or county_business_patterns_tool. The usage context is implied but not explicit.

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

rental_housing_toolRental Housing Finance ToolA
Read-onlyIdempotent

Retrieve rental housing finance data from the Rental Housing Finance Survey (RHFS). Get financial, mortgage, and property characteristics of rental housing properties in the United States. Data includes property configuration, expenses, ownership and management, income and subsidies, finances and mortgage, and capital improvements. Filter by property size (1 unit, 2-4 units, 5-24 units, etc.). National-level data only. Available for years 2015, 2018, and 2021.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNoYear for rental housing data. Available years: 2015, 2018, 2021. Default: 2021.2021
groupYesData group to retrieve. RHFS_PC: Property Configuration, RHFS_EX: Expenses, RHFS_OM: Ownership and Management, RHFS_IS: Income and Subsidies, RHFS_FM: Finances and Mortgage, RHFS_CI: Capital Improvements and Expenses.
propertySizeNoFilter by property size. 0: All properties (default), 1: 1 unit, 2: 2-4 units, 3: 5-24 units, 4: 25-49 units, 5: 50+ units. If not specified, returns all property sizes.

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context: 'National-level data only' and available years (2015, 2018, 2021), which are not in annotations. 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.

Conciseness5/5

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

The description is two sentences that efficiently convey the tool's purpose and key details (data types, filters, years, geographic scope). No superfluous text; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the schema covers all parameters and annotations indicate safety, the description is complete for an agent to understand the tool's scope. It covers national-level, years, data categories, and property size filters. The absence of output schema is compensated by listing what data is included. Slight gap: no mention of return format or limits, but acceptable.

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?

Schema coverage is 100% with good descriptions for each parameter. The description recaps the filter options (e.g., '1 unit, 2-4 units, etc.') and data groups, but adds little semantic value beyond the schema. Baseline of 3 is appropriate.

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 explicitly states this tool retrieves rental housing finance data from the RHFS survey. It lists specific data categories (property configuration, expenses, etc.) and filters (year, property size), making the purpose clear and distinct from sibling tools which cover other surveys (ACS, business, etc.).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives. It only describes the tool's functionality without stating when to prefer it or when not to use it. Sibling tools cover different domains, but no direct comparison is given.

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

tigerweb_toolTIGERweb Boundary ToolA
Read-onlyIdempotent

Retrieve geographic boundary polygons from TIGERweb as GeoJSON. Get actual boundary shapes for states, counties, tracts, block groups, and places. Returns standard GeoJSON FeatureCollection that can be used for mapping and spatial analysis. No API key required.

ParametersJSON Schema
NameRequiredDescriptionDefault
geographyTypeYesType of geographic boundary to retrieve
stateNoState FIPS code or 2-letter abbreviation (e.g., "06" or "CA")
countyNoCounty FIPS code (3 digits, required for tract and block group)
tractNoCensus tract code (6 digits, required for block group)
geoidNoFull GEOID to query specific feature (alternative to state/county/tract)
nameNoName to search for (e.g., "California", "Los Angeles County")
vintageNoData vintage (default: Current for most recent boundaries)Current
simplifyNoReturn simplified geometries for faster response (less detail)

Output Schema

ParametersJSON Schema
NameRequiredDescription
typeYes
featuresYes

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds that it returns GeoJSON FeatureCollection and requires no API key, but does not disclose other behavioral traits such as input validation behavior or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is three concise sentences, front-loading the main purpose, and contains no unnecessary fluff, though it could be slightly more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, flexible usage) and the presence of an output schema, the description adequately covers the core functionality and output format (GeoJSON FeatureCollection), but could provide more context on parameter relationships.

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 has 100% description coverage with 8 parameters; the description adds no substantive parameter details beyond the schema, such as how to use geoid vs. the hierarchical parameters or the meaning of simplify.

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 clearly states the tool retrieves geographic boundary polygons as GeoJSON, enumerates the types (states, counties, tracts, block groups, places), and indicates use for mapping and spatial analysis, differentiating it from sibling statistical tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions 'No API key required' as a convenience, but does not provide explicit guidance on when to use this tool versus alternatives like geocoding or data tools, nor does it state prerequisites or exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 17 tool updatesv0.1.2
    • First observedacs_data_tool
    • First observedannual_business_survey_tool
    • First observedbusiness_dynamics_statistics_tool
    • First observedcommunity_resilience_tool
    • First observedcounty_business_patterns_tool
    • First observeddecennial_census_tool
    • First observedeconomic_census_tool
    • First observedgeocoding_tool
    • First observedgeoinfo_tool
    • First observedhealth_insurance_tool
    • First observedinternational_database_tool
    • First observedpopulation_estimates_tool
    • First observedpoverty_statistics_tool
    • First observedpublic_sector_tool
    • First observedquarterly_workforce_indicators_tool
    • First observedrental_housing_tool
    • First observedtigerweb_tool
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool is clearly named and described to correspond to a specific Census survey or function. Overlap is minimal and descriptions clarify distinctions (e.g., decennial vs. population estimates).

Naming Consistency5/5

All tool names follow a consistent lowercase_underscore pattern with a descriptive prefix and '_tool' suffix. No mixing of conventions.

Tool Count4/5

With 17 tools covering a wide range of Census data products, the count is slightly above the typical well-scoped range but justified given the breadth of the domain.

Completeness4/5

The tool set covers major Census surveys and geospatial functions. Minor gaps exist (e.g., CPS, AHS), but core workflows for demographic, economic, and geographic data are well represented.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • city-data-mcp by zencity-product

    city-data-mcpofficial

    zencity-product
    F
    license
    Not graded
    quality
    C
    maintenance
    An MCP server that gives Claude deep access to US public data -- demographics, economics, crime, employment, weather, housing, transit, schools, budgets, and more across 30+ cities for government intelligence workflows.
    -

  • census-mcp-server

    zenlyticgreg
    F
    license
    Not graded
    quality
    C
    maintenance
    A production-grade MCP server for querying U.S. Census Bureau data (ACS 5-Year and Decennial) with tools for geographic fuzzy matching, variable search, and batched data retrieval, backed by a PostgreSQL cache for performance.
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mattpodwysocki/census-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server