← Directory
mcp · Global
capetown-opendata-mcp
A comprehensive MCP server for accessing Capetown Opendata
Claim this listing
Represent capetown-opendata-mcp? Send a claim for review so we can discuss listing updates. Claims do not automatically grant ownership or verification.
What's in it
- Data offered docs-verified
- load shedding block polygons · municipal ward boundaries · cadastral land parcels (erven) · registered minibus taxi routes · inland water quality sampling results (non-spatial) · public street lighting assets · heritage inventory sites and features · citizen service requests since 2023 (non-spatial, about 5 million rows) · building plan applications since 2014 (non-spatial) · generic query over any layer · distinct field values per layer · server-side summary statistics per layer
- Coverage llm-inferred
- City of Cape Town, South Africa · 2014 onward (building plan applications); 2023 onward (service requests)
- Resolution docs-verified
- Coordinates rounded to 6 decimal places (about 10 cm); simplified geometry generalised server-side to about 5 m
- Formats docs-verified
- MCP stdio · MCP streamable HTTP
- Access docs-verified
- Free and open source under the MIT licence; no authentication required by default; optional ArcGIS token for authenticated services
Useful for
- Use cases llm-inferred
- Site constraints screening: heritage inventory sites and land parcels within a bounding box for a Cape Town development · Planning context: ward boundaries and land parcels (erven) for a site's suburb · Water quality baseline: recent inland water quality sampling results for a study area · Planning precedent review: building plan approval counts by area using summarize_layer
- Audience llm-inferred
- GIS analysts · planners · environmental consultants · hydrologists · civils engineers
Limitations
- Constraints llm-inferred
- Covers City of Cape Town open data only; it does not provide UK data · Two ArcGIS servers are used; record counts differ between them on some layers, so the --server setting matters · Responses are capped at about 8,000 tokens by default, so large results need paging, fewer fields, or centroid geometry · service_requests and building_plan_approvals are non-spatial tables, so they take no bbox or polygon filters; use summarize_layer for counts · Published layer IDs can drift when the portal is republished, so discovery via service_info is preferred over hard-coded IDs · Some ODP_SPLIT services may be temporarily unavailable; service_info reports these · No data update frequency is stated; the default response cache TTL is 5 minutes · Maintenance relies partly on sponsorship, which the docs request for triage and dependency bumps
Example tool calls docs-verified
Fetch five municipal ward boundaries.
{
"tool": "wards",
"arguments": {
"limit": 5
}
}- Licence
- MIT
- Authentication
- Unknown — review source docs
- GitHub stars
- 5
- Last commit
- 07/10/2026
- Last successful page check
- 14/10/2026
- Page health
- healthy
- Package
- Not recorded
- Verification
- Not independently verified
Auto-extracted, unverified fields: tools, auth. Check upstream documentation.
Provenance & evidence
Daily discovery 2026-10-15: GitHub search; verified via GitHub API. Tools/install/auth auto-extracted from README.
Metadata observed 14/10/2026 · daily-2026-10-15 (github-search)