How do I use civic-library-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@civic-library-mcp check opportunity zone for 900 Camp St, New Orleans, LA 70130" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

civic-library-mcp

by adriancisnerosspeed-hub

Overview Schema Related Servers Score Discussions

TypeScript

Remote

civic-library-mcp

An MCP server that gives AI agents clean, token-efficient access to US civic & property data — geocoding, census tracts, Opportunity Zones, ACS demographics, and FEMA flood zones — sourced entirely from free federal open data.

No scraping, no paid keys for the core tools, no proprietary databases. Just the official sources (U.S. Census Bureau, U.S. Treasury CDFI Fund, FEMA), wrapped in a small set of well-described tools that return compact JSON instead of the bloated payloads most data MCPs dump into your context window.

Built for developers working on proptech, real-estate, fintech, civic tech, GIS, and housing research with AI agents.

Tools

Tool	What it does	API key?
`geocode_address`	US street address → lat/lng + state, county, and 2020 census tract GEOID	None
`lookup_census_tract`	lat/lng → the 2020 census tract (with county/state) containing that point	None
`check_opportunity_zone`	Is this address / point / tract in a designated Qualified Opportunity Zone?	None
`get_tract_demographics`	ACS 5-Year indicators (income, population, home value, poverty rate, …) for a tract	Free Census key
`check_flood_zone`	lat/lng → FEMA flood-hazard zone + whether it's a Special Flood Hazard Area	None

Four of the five tools work with zero configuration. Only get_tract_demographics needs a free Census API key (see below).

Related MCP server: Census MCP Server

Install

Claude Desktop / Cursor / any MCP client

Add to your MCP config (e.g. claude_desktop_config.json):

{
  "mcpServers": {
    "civic-library": {
      "command": "npx",
      "args": ["-y", "civic-library-mcp"],
      "env": {
        "CENSUS_API_KEY": "your-free-census-key-optional"
      }
    }
  }
}

Claude Code

claude mcp add civic-library -- npx -y civic-library-mcp

The CENSUS_API_KEY line is optional — leave it out and four of the five tools still work.

Census API key (only for demographics)

get_tract_demographics calls the U.S. Census ACS Data API, which requires a free key. Get one in ~30 seconds at https://api.census.gov/data/key_signup.html and set it as CENSUS_API_KEY in the server's environment.

Examples

Check whether a property is in an Opportunity Zone:

// check_opportunity_zone({ "address": "900 Camp St, New Orleans, LA 70130" })
{
  "is_opportunity_zone": true,
  "tract_geoid_2010": "22071013400",
  "designation_type": "Low-Income Community",
  "round": "1.0",
  "authority": "Tax Cuts and Jobs Act of 2017 (26 U.S.C. § 1400Z-1)",
  "resolved_from": "address",
  "source": "U.S. Treasury CDFI Fund (designated 2018-12-14)"
}

Flood risk for a coordinate:

// check_flood_zone({ "latitude": 29.9511, "longitude": -90.0715 })
{
  "flood_zone": "X",
  "zone_subtype": "0.2 PCT ANNUAL CHANCE FLOOD HAZARD",
  "in_special_flood_hazard_area": false,
  "zone_description": "Moderate-to-minimal risk (outside the 1% annual-chance floodplain).",
  "source": "FEMA National Flood Hazard Layer"
}

Tract demographics (needs a key):

// get_tract_demographics({ "tract_geoid": "22071013400",
//   "fields": ["population", "median_household_income", "poverty_rate"] })
{
  "tract_geoid": "22071013400",
  "tract_name": "Census Tract 134, Orleans Parish, Louisiana",
  "acs_dataset": "ACS 5-Year 2023",
  "population": 2276,
  "median_household_income": 41250,
  "poverty_rate": 0.231
}

A note on correctness: Opportunity Zones use 2010 census tracts

Opportunity Zone designations are keyed to 2010 census tract boundaries, but the default Census geocoder returns 2020 tracts — and tract GEOIDs changed between the two vintages. A naive lookup that matches a 2020 GEOID against the OZ list will silently return wrong answers near any boundary that moved.

check_opportunity_zone handles this correctly: it re-resolves the address/coordinate to its 2010 tract before matching. (You can see the difference — the same address can yield GEOID …980000 from geocode_address and …006202 from check_opportunity_zone.) If you pass tract_geoid directly, it's treated as a 2010 GEOID.

Data sources & licensing

Data	Source	Notes
Geocoding & census tracts	U.S. Census Bureau Geocoder	Public domain
Opportunity Zones	U.S. Treasury CDFI Fund	Round 1 (2018) designations, 8,764 tracts, bundled
Demographics	U.S. Census ACS 5-Year	Public domain; free key required
Flood zones	FEMA National Flood Hazard Layer	Public domain

All underlying data is U.S. federal open data (public domain). This software is MIT-licensed.

The bundled Opportunity Zone list is regenerated with npm run build:oz.

Roadmap

OZ 2.0 — designations under the One Big Beautiful Bill Act (2025) once finalized/published.
More ACS fields — educational attainment, race/ethnicity, housing tenure, commute.
County parcel / CAD lookups — added per-county only where the source's terms of use permit automated access.
Census place & ZIP geographies, FEMA base flood elevations.

Disclaimer

This tool surfaces public government data for informational purposes. It is not legal, financial, tax, insurance, or investment advice. Opportunity Zone, flood-zone, and demographic determinations should be confirmed against the official source of record before relying on them for any transaction. Data is provided "as is" with no warranty.

Contributing

Issues and PRs welcome — especially additional federal open-data sources and ACS fields. Keep responses compact (token cost is a feature) and every data point attributed to its source.

License

Available Tools

5 tools

check_flood_zoneCheck FEMA flood zoneA

Return the FEMA flood-hazard zone for a latitude/longitude point, including whether it falls in a Special Flood Hazard Area (SFHA, where flood insurance is typically required). Free, no API key. Source: FEMA National Flood Hazard Layer.

ParametersJSON Schema

Name	Required	Description	Default
`latitude`	Yes	Latitude in decimal degrees (WGS84)
`longitude`	Yes	Longitude in decimal degrees (WGS84)

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the tool performs a read-only lookup via 'Return', checks SFHA status, requires no API key, and cites the FEMA NFHL source. It does not cover error handling or data freshness, but for a simple point-query tool this 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.

Conciseness5/5

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

The description is three terse sentences: the first states the core function, the second addresses access (free, no key), and the third names the data source. Every sentence adds value and the structure is front-loaded with the most important information.

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 low-complexity tool with no output schema, the description sufficiently explains the returned concept (flood-hazard zone and SFHA eligibility) and provides access and source context. It lacks explicit output format details, but that is not critical for a simple lookup. The description is complete enough 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.

Parameters3/5

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

The schema already provides full parameter descriptions (latitude/longitude in decimal degrees WGS84) with 100% coverage, so the baseline is 3. The description merely echoes 'latitude/longitude point' without adding any new parameter nuances, such as coordinate order or bounds.

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 ('Return') and identifies the resource ('FEMA flood-hazard zone') with clear scope ('for a latitude/longitude point, including whether it falls in a Special Flood Hazard Area'). This clearly distinguishes it from sibling tools like geocode_address and lookup_census_tract.

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 by stating the tool's purpose and noting that it is free with no API key, which helps the agent infer when to use it. However, it does not explicitly state situations to avoid or name alternative tools, so it misses the bar for a 5.

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

check_opportunity_zoneCheck Opportunity Zone statusA

Determine whether a location is in a designated Qualified Opportunity Zone (Round 1, Tax Cuts and Jobs Act of 2017). Accepts an address, a lat/lng, or an 11-digit 2010 census tract GEOID. OZ designations are keyed to 2010 tracts, so address/coordinate inputs are resolved to their 2010 tract automatically. Free, no API key.

ParametersJSON Schema

Name	Required	Description
`address`	No	US street address (resolved to its 2010 census tract)
`latitude`	No	Latitude (use with longitude)
`longitude`	No	Longitude (use with latitude)
`tract_geoid`	No	An 11-digit 2010 census tract GEOID

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the transparency burden. It discloses that the tool is free, requires no API key, and auto-resolves address/coordinate inputs to 2010 census tracts, plus the Round 1 limitation. It stops short of describing the return format or error behavior, but covers the key traits for a simple lookup.

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-loaded with the core purpose immediately. It includes all necessary context without redundancy, making it both 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?

For a single-purpose lookup tool with 100% schema coverage, the description covers the main use case, input formats, resolution behavior, and cost/auth. It does not mention the response shape or whether multiple inputs are mutually exclusive, but these are minor omissions given the tool's simplicity.

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%, so baseline is 3. The description adds value by making explicit that address, lat/lng, and tract_geoid are alternative input modes and that address/coordinates are resolved to 2010 tracts. This goes beyond the schema's individual parameter descriptions.

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

Purpose5/5

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

The description clearly states the tool's purpose: to determine whether a location is in a designated Qualified Opportunity Zone (Round 1, TCJA 2017). It specifies the resource (OZ status) and the exact scope, distinguishing it from siblings like check_flood_zone and lookup_census_tract.

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 on accepted inputs (address, lat/lng, or GEOID) and explains the automatic resolution to 2010 tracts. However, it does not explicitly mention when to use this tool over alternatives (e.g., check_flood_zone) or provide exclusions.

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

geocode_addressGeocode a US addressA

Convert a US street address into latitude/longitude plus its Census geographies (state, county, 2020 census tract GEOID). Free, no API key. Source: U.S. Census Bureau Geocoder.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	A US street address, e.g. '1600 Pennsylvania Ave NW, Washington, DC 20500'

TDQS

A4/5.0

Behavior3/5

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

With no annotations available, the description carries the burden of behavioral disclosure. It usefully mentions the free nature, lack of API key, and data source (Census Bureau), but does not disclose rate limits, error behavior, or output format details beyond the listed geographies.

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 extremely concise, using two short sentences and a source attribution. It front-loads the core action and adds only necessary context about cost and source, with no waste.

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 single-parameter tool with no output schema, the description adequately outlines the input and expected outputs (lat/long, geographies). It could be more complete by explaining potential failure modes or usage limits, but overall it is sufficient for basic invocation.

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 schema already fully describes the 'address' parameter with an example, so the description adds little parameter-specific meaning. The mention of 'US street address' reinforces the schema but does not go beyond 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 states the tool's function: converting a US street address into latitude/longitude and Census geographies. This specific verb+resource distinguishes it from sibling tools that operate on census tracts or zones rather than addresses.

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 implicitly indicates this is for address-to-geography conversion, which contrasts with siblings like lookup_census_tract or check_flood_zone. It does not explicitly exclude other use cases or name alternatives, but the context is clear.

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

get_tract_demographicsGet census tract demographics (ACS 5-Year)A

Return demographic indicators for an 11-digit census tract GEOID from the American Community Survey 5-Year (2023). Requires a free Census API key in the CENSUS_API_KEY environment variable (get one instantly at https://api.census.gov/data/key_signup.html). Available fields: population, median_household_income, median_home_value, median_gross_rent, median_age, households, poverty_rate. Omit 'fields' to get a sensible default set.

ParametersJSON Schema

Name	Required	Description	Default
`fields`	No	Which indicators to return. Defaults to: population, median_household_income, median_home_value, poverty_rate
`tract_geoid`	Yes	An 11-digit census tract GEOID (state[2] + county[3] + tract[6])

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description covers behavioral traits directly. It discloses the API key requirement, provides a sign-up link, and mentions the default field set when 'fields' is omitted. While it does not describe error handling or output format, these are minor for a simple retriever; the key prerequisite and default behavior are clearly stated.

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 purpose, then provides an essential prerequisite, a field list, and a usage note—all in three short sentences. No unnecessary words; every sentence contributes 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?

For a simple read-only tool with two parameters, the description covers the core functionality, required input, available fields, and default behavior. It does not explain return format or error cases, but given the simplicity and lack of an output schema, this is a minor gap. The description is sufficiently complete for most use cases.

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 both parameters fully described. The description adds little beyond the schema: it lists the available fields (matching the enum) and mentions the default set, but the schema already documents the default. Thus, the description does not significantly enhance parameter understanding beyond structured data.

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 ('Return') and resource ('demographic indicators for an 11-digit census tract GEOID'), and clearly distinguishes the tool from siblings by focusing on demographic data from the ACS 5-Year. The title and first sentence work together to convey exactly what is provided.

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 sets clear context: this tool returns demographic data for a tract GEOID. It also mentions a prerequisite (API key) and gives a link to obtain it. However, it does not explicitly discuss when to use this tool over siblings like lookup_census_tract or check_opportunity_zone, though the purpose is distinct enough.

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

lookup_census_tractLook up the census tract for a coordinateA

Return the 2020 census tract (with county and state) that contains a latitude/longitude point. Free, no API key. Source: U.S. Census Bureau Geocoder.

ParametersJSON Schema

Name	Required	Description	Default
`latitude`	Yes	Latitude in decimal degrees (WGS84)
`longitude`	Yes	Longitude in decimal degrees (WGS84)

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It adds useful context such as 'Free, no API key' and the data source, and specifies the census year (2020). However, it does not disclose potential limitations like US-only coverage or behavior for coordinates outside any tract, which would be relevant for a geocoding tool.

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 only two sentences and front-loads the main purpose. Every piece of information ('2020 census tract', 'county and state', 'latitude/longitude', 'free', 'no API key', 'source') adds value without unnecessary verbosity.

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 tool is simple with only two parameters and no output schema. The description covers the core purpose, return content, and access constraints. It could be considered slightly incomplete for not mentioning that census tracts are US-only or what happens for points outside the US, but overall it provides enough context for a straightforward lookup tool.

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

Parameters3/5

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

The input schema already provides full descriptions for both parameters (latitude and longitude in decimal degrees, WGS84), so schema coverage is 100%. The description adds minimal semantic value beyond what the schema provides, only referring to 'a latitude/longitude point', which is adequate given the high schema coverage.

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 action ('Return') and the resource ('2020 census tract') along with additional context (county and state) and input (latitude/longitude). It effectively distinguishes itself from sibling tools like geocode_address (which likely goes from address to coordinates) and get_tract_demographics (which focuses on demographics for a given tract).

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 implies use when given a coordinate and needing the census tract, and notes it is free and requires no API key. It does not explicitly mention when not to use it or name alternatives, but the context and sibling tool list make the appropriate use case clear.

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.

5 tool updatesv0.1.2Aug 13, 2026
- First observedcheck_flood_zone
- First observedcheck_opportunity_zone
- First observedgeocode_address
- First observedget_tract_demographics
- First observedlookup_census_tract

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation4/5

Most tools are clearly distinct, but geocode_address and lookup_census_tract overlap in that geocode_address can already provide tract information for an address, while lookup_census_tract does so for coordinates. check_opportunity_zone also accepts multiple input types, potentially causing confusion about which tool to use for a given input.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: geocode_address, lookup_census_tract, check_opportunity_zone, get_tract_demographics, check_flood_zone. There is no mixing of styles or ambiguous naming.

Tool Count5/5

With exactly 5 tools, the server is well-scoped for a civic data lookup library. Each tool serves a distinct purpose and there are no redundant or filler tools.

Completeness4/5

The tool set covers the key workflows: address to coordinates/tract, reverse geocoding, opportunity zone checks, demographics, and flood zones. A minor gap is the lack of a 2010 census tract lookup for compatibility with check_opportunity_zone, but since that tool can accept addresses/coordinates directly, it's not a dead end.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

openfolio
io.github.dodenbach
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
Government Data Open Data Search
1
nyc-property-intel
io.github.ccedacero
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
Real Estate Government Data
27
public-queryOAuth
com.amalgament
Agent-native MCP over US public + government records, entity- and parcel-keyed.
Government Data Open Data
1
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2

Related MCP Servers

Dilix MCPofficial
Real Estate Finance Government Data
Dilix-Ai
A
license
A
quality
C
maintenance
Open-source MCP server providing real estate regulatory intelligence (zoning, permits, entitlements, deal scoring) for US properties, enabling AI agents to access 10 callable tools.
Updated 3 months ago (2026-06-15 05:06 UTC)
12
15
MIT
Census MCP Server
Government Data Open Data Research & Data
mattpodwysocki
A
license
A
quality
C
maintenance
Node.js MCP server enabling AI agents to access comprehensive U.S. Census Bureau demographic and economic data, including ACS, decennial census, and business patterns.
Updated 7 months ago (2026-01-27 23:12 UTC)
17
1,211
MIT
city-data-mcpofficial
Government Data Open Data
zencity-product
F
license
Not graded
quality
D
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.
Updated 5 months ago (2026-04-19 06:52 UTC)
-
mcp-hazards
Weather Services Location Services Open Data
jsuich
A
license
Not graded
quality
B
maintenance
An MCP server that gives AI agents grounded access to US natural-hazard data — weather alerts, forecasts, earthquakes, and FEMA flood zones — from free, keyless US government APIs.
Updated 2 months ago (2026-07-13 15:39 UTC)
MIT

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/adriancisnerosspeed-hub/civic-library-mcp'

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

civic-library-mcp

Tools

Install

Claude Desktop / Cursor / any MCP client

Claude Code

Census API key (only for demographics)

Examples

A note on correctness: Opportunity Zones use 2010 census tracts

Data sources & licensing

Roadmap

Disclaimer

Contributing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Dilix MCPofficial

city-data-mcpofficial

Latest Blog Posts

MCP directory API