Census MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.2
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.
Average 3.9/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on January 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![census-mcp-server MCP server](https://glama.ai/mcp/servers/mattpodwysocki/census-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/mattpodwysocki/census-mcp-server)

Score Badge

Copy to your README.md:

[![census-mcp-server MCP server](https://glama.ai/mcp/servers/mattpodwysocki/census-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/mattpodwysocki/census-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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