census-mcp

by mcpwright

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation5/5
Each tool has a clearly distinct purpose: validation, metric-specific lookups, comparison, reverse lookup, and raw ACS access. There is no overlap or ambiguity between them.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (lookup_zip, get_income, compare_zips, etc.). No mixed styles or vague verbs.
Tool Count5/5
8 tools is well-scoped for a census data server. Each tool covers a meaningful aspect of the domain without bloat or redundancy.
Completeness4/5
The set covers core census data needs: validation, income, demographics, housing, education, comparison, reverse lookup, and raw variable access. Minor gaps like age-bracket breakdowns exist but are noted as roadmap, and the raw access tool mitigates many limitations.
Average 4.5/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- Last stable release on June 10, 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it specifies the population base (aged 25 and over), the exact metrics (bachelor's+ and graduate degree percentages), and the data source (ACS 5-year estimates). This is valuable context beyond the readOnlyHint and openWorldHint 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 very concise and front-loaded. The first sentence gives the primary purpose in a compact format ('Educational attainment for a ZIP: % bachelor's+ and % graduate degree.'), and the second sentence adds essential details. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, an output schema, and clear annotations, the description is complete. It covers the purpose, the parameter format, the population denominator, the metrics, and the data source. There is no missing critical information that would prevent an agent from using the tool correctly.
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?
The description explicitly explains the zip_code parameter: '`zip_code`: a 5-digit US ZIP.' This adds format validation (5-digit) and clarifies its role, which is crucial since the input schema only defines it as a string with no description. The schema coverage is 0%, so this compensation is welcome.
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 states what the tool does: 'Educational attainment for a ZIP: % bachelor's+ and % graduate degree.' It specifies the resource (ZIP) and the data returned (education percentages), making the purpose clear. However, it does not explicitly distinguish itself from sibling tools like get_income or get_demographics, but the focus on education is specific enough to separate it.
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 by context: it says 'Of the population aged 25 and over, returns the percent...' which suggests it is to be used when education data for a ZIP is needed. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description directly contradicts the openWorldHint annotation by stating it is 'Limited to the variables held in the local store.' This is a clear closed-world claim, whereas openWorldHint implies the tool may access dynamic external data. Such a contradiction can mislead the agent about the tool's behavior.
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 compact and front-loaded with the core purpose, followed by parameter details and constraints. Every sentence adds value, and the formatting with code examples improves clarity without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only lookup with an output schema present, the description covers input formats, case-insensitivity, scope limitations, and error behavior. The only flaw is the annotation contradiction, but the description itself is fully self-contained for invocation purposes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description carries the full burden for parameter meaning and excels. It specifies zip_code as a 5-digit US ZIP and variable as either an ACS variable code or a friendly store-column name, both case-insensitive. This adds rich detail beyond the bare property titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Raw value of a single ACS variable for a ZIP' — a specific verb+resource pair that clearly states what the tool does. The 'escape hatch' framing explicitly distinguishes it from the named sibling tools like get_income and get_demographics, which target specific variable sets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'escape hatch' label provides explicit guidance: use this tool when the other, more targeted siblings don't cover a desired variable. It also notes that unknown variables error with the full list, which helps the agent understand failure mode and fallback behavior.
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 openWorldHint=true, and the description adds that the data are ACS 5-year estimates and that age-bracket breakdowns are on the roadmap. This provides useful context beyond the annotations without contradicting them.
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 (or three lines) long, front-loaded with the core purpose, and includes only essential details like the parameter format and the roadmap limitation. Every word earns its place.
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 simple read-only tool with one parameter and an output schema, the description covers the purpose, the parameter format, the data source, and what is not yet included. It is sufficiently complete without needing to explain return values in detail.
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?
The schema provides no description for zip_code (0% coverage), but the description includes '`zip_code`: a 5-digit US ZIP,' which supplies the format and meaning. This compensates for the schema gap.
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 that the tool returns population and median age for a ZIP, using the verb 'Returns' in the second sentence. It distinguishes itself from sibling tools like get_income or get_housing by naming the specific metrics it provides.
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?
Usage is implied: use when you need population and median age for a ZIP. There is no explicit mention of when not to use it or which alternative to pick for other demographics, though the roadmap note hints that age-bracket breakdowns are not yet available.
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 the description adds valuable behavioral details: results are sorted descending, ZIPs with missing data are listed last, and values are ACS 5-year estimates. This goes beyond the annotations and helps the agent understand output ordering and data provenance.
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 compact yet information-dense. It front-loads the core purpose in one sentence, then efficiently documents parameters and behavioral details in a bullet-like list embedded in prose. Every sentence adds value, with no fluff or 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?
With an output schema present, the description need not explain return format, and it wisely covers the essential behavioral aspects: sorting, missing-data handling, and the metric enum. It is slightly less explicit about when to prefer this over sibling tools, but it is complete enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates: it defines 'zips' as a list of 5-digit US ZIPs and provides the complete list of allowed values for 'metric'. Without this, the agent would have no idea what values are valid or what each parameter means.
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 starts with a specific verb ('Rank') and resource ('several ZIPs'), immediately distinguishing it from sibling tools that operate on single ZIPs or specific metrics. It also enumerates the exact metrics, leaving no ambiguity about what the tool does.
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 clearly indicates the tool is for comparing multiple ZIPs on a single metric, which provides strong contextual guidance. It does not explicitly name alternatives or exclusion criteria, but the sibling list and the phrase 'several ZIPs' imply when this tool is appropriate versus single-lookup tools.
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?
Beyond the readOnlyHint and openWorldHint annotations, the description adds valuable behavioral context: the ~2% error rate for ZIPs without ZCTAs and the return of the ACS data vintage. This helps the agent anticipate edge cases.
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 compact and front-loaded with the core purpose. It includes a param note and caveat without excessive detail, though the structure is slightly dense with multiple ideas in a few sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only tool with an output schema available, the description covers purpose, parameter, usage context, and error behavior. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for zip_code (0% coverage), but the tool description fully explains it as a 5-digit US ZIP and its role in validation. This completely compensates for the schema gap.
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 confirms a ZIP maps to a Census ZCTA and returns its name and population, using a specific verb and resource. This distinguishes it from sibling tools like get_income or find_zips.
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 usage context by calling it 'a good first call to validate a ZIP before asking for more detail.' However, it doesn't explicitly name alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the ACS top-coding limit ($250,001) and explains how to interpret the result for wealthy ZIPs, which is critical behavioral context beyond the readOnlyHint and openWorldHint annotations. It also specifies data source and units, adding meaningful transparency.
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 front-loaded with the core purpose, followed by a concise parameter explanation and a crucial caveat. Every sentence adds value, with no redundancy or padding.
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?
The tool is simple (single parameter, no enums), and the description covers the data source, the top-coding nuance, and the parameter format. The presence of an output schema handles return values, so the description is complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for zip_code, but the description fully compensates by explicitly defining it as a 5-digit US ZIP and connecting it to the returned metrics. This is a clear, complete explanation of the parameter's 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 the tool provides ZIP-level income measures, enumerating median household income, per-capita income, and % $200k+. It differentiates itself from siblings by focusing specifically on income, not demographics or housing.
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 income data but does not explicitly compare with alternatives like get_demographics or compare_zips. It lacks clear 'when to use' or 'when not to use' statements, leaving guidance implied rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, but the description adds valuable context beyond those: the approximate nature of ZCTA/place relationships, the ranking by coverage_pct, and the data source. It also clarifies that no API key is needed. This enriches the behavioral understanding without contradicting 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 well-structured and front-loaded: the opening sentence states the core function, followed by parameter details, ranking, caveats, and data source in a logical flow. Every sentence contributes value, and the length is appropriate for the tool's complexity.
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 tool's moderate complexity and the presence of an output schema, the description covers all necessary aspects: purpose, parameters, output ranking, limitations (approximate), and data provenance. It is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining both parameters in detail: place is a named US city/town/CDP with examples, and state is optional with formats. It also clarifies the meaning of coverage_pct in relation to the output, which goes beyond the schema's type-only definitions.
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 uses a specific verb and resource: 'Reverse lookup: the ZIPs (ZCTAs) that fall within a named place.' This clearly distinguishes it from sibling tools like lookup_zip (which presumably does the forward lookup) and other data tools. The purpose is unambiguous and specific.
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 gives clear context for when to use the tool: when you have a U.S. place name and need the intersecting ZCTAs. It notes that state disambiguates, implying when to supply that parameter. However, it does not explicitly contrast with alternatives or mention when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses important behavioral details: it returns ACS 5-year estimates and calls out the top-coding caveat for median home value at $2,000,001, explaining that values like Atherton's 94027 represent '$2M or more' rather than exact figures. This adds significant interpretive 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?
The description is compact and well-structured, around 100 words across three sentences plus a note. Every sentence contributes: the first introduces the metrics, the second defines the input and return fields, and the third adds a crucial caveat. No filler or redundancy.
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 output schema exists, the description need not restate return formats. It covers the essential context: data source (ACS 5-year), the specific variables, and a critical interpretation warning. This is complete for a single-ZIP housing data tool with strong annotations and an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only labels zip_code as 'Zip Code' with type string (0% schema description coverage). The description compensates fully by stating that zip_code is a 5-digit US ZIP and providing an example (Atherton 94027) within a realistic context, giving the agent precise format and usage guidance.
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?
Description clearly identifies the tool as providing housing measures for a ZIP, specifically home value, rent, and owner-occupied share. This distinguishes it from sibling tools like get_income or get_demographics by naming the exact metrics returned.
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 conveys a clear context for use — 'Housing measures for a ZIP' — and enumerates the variables, making it obvious when this tool is appropriate. It does not explicitly exclude alternatives or name sibling tools, but the context is strong enough to guide selection.
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 MCP server](https://glama.ai/mcp/servers/mcpwright/census-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mcpwright/census-mcp)

Score Badge

Copy to your README.md:

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

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/mcpwright/census-mcp'

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