Provides geospatial reachability and catchment-scoring tools for out-of-home (OOH) site evaluation, using OpenStreetMap data for geocoding, POI queries, and isochrone generation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Open Reach Rank 3 billboard sites near KLCC, Bukit Bintang, Mont Kiara by 10-min walk catchment."
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.
An MCP server for out-of-home (OOH) site-reachability tooling.
Open Reach exposes geospatial reachability and catchment-scoring tools for billboard / ad-site evaluation — isochrone catchments, POI-density scoring, and multi-site comparison — to any MCP client (Claude Desktop, Cursor, etc.), built entirely on open geospatial data and public urban-analytics methodology.
The differentiator is server-side reach scoring and multi-site ranking (
site_reach_score,compare_sites). There are several public OSM-wrapper MCP servers already; none of them do catchment scoring. That gap — plus honest, public methodology — is the point of this project.
You (in Claude Desktop):
"I'm scouting 3 candidate billboard sites near KLCC, Bukit Bintang, and
Mont Kiara. Which has the best pedestrian catchment and highest POI
density within a 10-minute walk?"
Claude:
→ geocode("KLCC"), geocode("Bukit Bintang"), geocode("Mont Kiara")
→ isochrone(..., mode="walk", minutes=10) [x3]
→ catchment_pois(..., categories=["cafe","retail","transit"]) [x3]
→ site_reach_score(...) [x3]
→ compare_sites(sites=[...], minutes=10, mode="walk")
← ranked: 1. Bukit Bintang 2. KLCC 3. Mont Kiara (with per-site breakdown)The ranking arithmetic runs server-side in compare_sites — the model's job
is orchestration and narration, not the math.
Related MCP server: @nor-data/nabolag-mcp
┌─────────────────────┐ MCP (JSON-RPC over stdio)
│ MCP Client │ ──────────────────────────────┐
│ (Claude Desktop / │ │
│ Cursor / Code) │ ◄── tool schemas advertised │
└─────────────────────┘ ▼
┌────────────────────────────────────┐
│ Open Reach MCP Server │
│ (FastMCP process) │
│ │
│ @mcp.tool: geocode │
│ @mcp.tool: reverse_geocode │
│ @mcp.tool: isochrone │
│ @mcp.tool: catchment_pois │
│ @mcp.tool: site_reach_score ★ │
│ @mcp.tool: compare_sites ★ │
│ │
│ TTL cache + per-host rate limiting │
└──────────────────┬───────────────────┘
│ https GET/POST
┌──────────────────────────────────┼───────────────────────┐
▼ ▼ ▼
┌───────────────────┐ ┌──────────────────────┐ ┌───────────────────┐
│ OSM Nominatim │ │ Overpass API │ │ OSRM │
│ (geocoding) │ │ (POIs by category) │ │ (isochrones) │
└───────────────────┘ └──────────────────────┘ └───────────────────┘Each scoring tool chains isochrone → POIs/junctions → a pure, unit-tested arithmetic module, then returns a typed result plus an auditable breakdown.
Tool | Description | Units |
| Forward geocode a place name. | lat/lon decimal degrees |
| Coordinate → address string. | decimal degrees → string |
| Reachable-area polygon within a time budget. | minutes; polygon |
| POIs in the catchment, grouped by enum category. | counts |
| Composite reach score | unitless |
| Deterministic multi-site ranking. ★ | ranks (1 = best) |
mode ∈ {walk, drive, transit}. categories are enum-constrained — callers
never supply raw Overpass QL; all queries are built server-side.
git clone https://github.com/kasturi/open-reach-mcp.git
cd open-reach-mcp
python -m venv .venv && .venv\Scripts\activate # Windows
# source .venv/bin/activate # macOS/Linux
pip install -e ".[dev]"Run standalone (stdio):
open-reach-mcp # or: python -m open_reach_mcpAdd to claude_desktop_config.json (macOS:
~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"open-reach": {
"command": "C:\\path\\to\\open-reach-mcp\\.venv\\Scripts\\open-reach-mcp.exe",
"args": []
}
}
}Set
USER_AGENT(see.env.example) to a descriptive value — Nominatim usage policy requires it.
pytest --cov=open_reach_mcp --cov-report=term-missingThe reach-scoring formula in site_reach_score is derived only from public
urban-analytics literature, not from any proprietary methodology or real
campaign/device data:
Gravity-model catchment accessibility (Hansen, 1959; classic spatial
interaction) — each POI contributes exp(-d / D) where d is its distance
from the site and D a pedestrian decay constant.
Walkability-style density indices — POI density and road-junction density
per km², normalized against public reference benchmarks to [0, 1].
Category-mix diversity via normalized Shannon entropy.
This project stands for the engineering pattern (geospatial proxy scoring under rate-limited free APIs, packaged as an MCP server). It is not a claim of parity with any production reach/audience system, and it uses no proprietary formulas or real client data.
All upstream APIs are free-tier and shared/public, so they are rate-limited and occasionally fragile. Open Reach mitigates this with:
TTL cache (CACHE_TTL_SECONDS, default 24h) + per-host rate limiting
(RATE_LIMIT_MIN_INTERVAL_SECONDS, default 1s — Nominatim's policy ceiling).
A compliant User-Agent header (configurable; required by Nominatim).
transit mode falls back to the OSRM foot profile — OSRM has no transit
router. For real transit isochrones, self-host a transit router (e.g.
RAPTOR/OTP) and point OSRM_BASE_URL at it. This is a known limitation, stated
openly rather than hidden.
For production throughput, self-host Nominatim / Overpass / OSRM (Docker
images exist for all three) and set the *_BASE_URL env vars. Turning upstream
fragility into a documented self-host path is part of the point.
All settings are environment-driven (see .env.example):
Variable | Default | Purpose |
|
| Geocoding upstream |
|
| POI upstream |
|
| Routing upstream |
|
| Required by Nominatim policy |
|
| TTL cache sizing |
|
| Per-host request spacing |
|
| Upstream call timeout |
v1 ships stdio transport. Publishing steps (run manually after build):
PyPI: python -m build && twine upload dist/*.
Official MCP registry: submit server.json (verified GitHub ownership) at
registry.modelcontextprotocol.io.
PyPI alone no longer supports a "published to the registry" claim; the official
registry (launched Sept 2025) requires the manifest + verified ownership.
SSE-only transports are deprecated since MCP spec 2025-03-26. A Streamable HTTP transport is the planned v2 stretch (no SSE).
MIT — see LICENSE.
Points of interest inside a site's catchment, grouped by category.
Units: lat/lon decimal degrees; minutes minutes. categories is
enum-constrained (no free-text queries).
Example: catchment_pois(lat=3.15, lon=101.71, minutes=10, mode="walk",
categories=["cafe","retail"])
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| mode | Yes | Routing mode for reachability/isochrone computation. | |
| minutes | Yes | ||
| categories | Yes |
| Name | Required | Description |
|---|---|---|
| lat | Yes | Latitude in decimal degrees [-90, 90]. |
| lon | Yes | Longitude in decimal degrees [-180, 180]. |
| mode | Yes | |
| total | Yes | |
| minutes | Yes | |
| by_category | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavior. It mentions that categories are enum-constrained (no free-text queries) and gives units, but does not address rate limits, errors, or how results are grouped. The output schema exists but is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a code example, front-loaded with the main purpose. Every sentence adds value, and the example illustrates usage effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 focuses on inputs. It covers the core idea and units, but lacks details on parameter constraints (e.g., lat/lon ranges, max minutes, max categories) and does not clarify how it relates to sibling tools like isochrone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so the description should compensate. It only adds that categories are enum-constrained (already in schema) and shows an example. It does not describe lat, lon, minutes, or mode beyond the example, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns points of interest inside a site's catchment, grouped by category. It provides specific details like units (decimal degrees, minutes) and an example, which helps distinguish it from siblings like geocode or isochrone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining POIs within a catchment area but does not explicitly state when to use this tool over alternatives like isochrone or site_reach_score. No when-not 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.
Rank candidate sites by reach score (server-side, deterministic).
Ranking is computed here, not by the client model. Tie-break chain:
score desc, POI density desc, category diversity desc, name asc.
Units: lat/lon decimal degrees; minutes minutes.
Example: compare_sites(sites=[{"name":"KLCC","lat":3.16,"lon":101.71},
{"name":"Bukit Bintang","lat":3.15,"lon":101.72}],
minutes=10, mode="walk")
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Routing mode for reachability/isochrone computation. | |
| sites | Yes | ||
| minutes | Yes | ||
| weights | No | ||
| categories | No |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| sites | Yes | |
| minutes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions server-side computation and deterministic ranking, but lacks details on auth, rate limits, or side effects (though it is a read-like operation). The tie-break chain and units are helpful, but more context could be added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two focused sentences plus an example. Every sentence adds value: purpose, tie-break, units, and usage illustration. No redundant or fluff content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and an output schema (not shown), the description covers core algorithm, tie-break, and example. It could briefly explain the effect of weights and categories parameters, but overall is adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20%), but the schema itself describes most parameters (mode, sites fields, weights, categories). The description adds an example and the tie-break chain, but does not explain minutes or weights in text. It compensates partially, but not fully for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: ranking candidate sites by reach score, server-side and deterministic. It distinguishes from siblings by implying this is for multiple-site comparison (vs. single-site tools like site_reach_score) and includes tie-break chain and units.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ranking multiple sites via example and tie-break details, but does not explicitly state when to use vs. alternatives (e.g., isochrone, site_reach_score) or provide exclusions. No when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Forward geocode a place name to a WGS84 coordinate (decimal degrees).
Units: latitude/longitude in decimal degrees. Example: geocode(query="KLCC") -> GeoPoint(lat=3.1579, lon=101.7116)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| lat | Yes | Latitude in decimal degrees [-90, 90]. |
| lon | Yes | Longitude in decimal degrees [-180, 180]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains output units and provides an example. It could mention rate limits or authorization, but the transparency is sufficient for a simple read-only 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences plus an example, front-loaded with the purpose. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple input schema with one parameter and an output schema (though not detailed), the description covers input, output format, units, and an example, making it complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'query' parameter has 0% schema description coverage, but the description clarifies it is a 'place name' and gives an example, adding necessary meaning beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('geocode') and resource ('place name to WGS84 coordinate'), and the sibling 'reverse_geocode' implies the opposite direction, distinguishing this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates forward geocoding usage but does not explicitly state when not to use it or provide alternatives beyond the implied reverse geocode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reachable-area polygon within a travel-time budget.
Units: lat/lon in decimal degrees; minutes in minutes; polygon ring
as [lon, lat] pairs; area_m2 in square metres.
Example: isochrone(lat=3.15, lon=101.71, mode="walk", minutes=10)
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| mode | Yes | Routing mode for reachability/isochrone computation. | |
| minutes | Yes |
| Name | Required | Description |
|---|---|---|
| lat | Yes | Latitude in decimal degrees [-90, 90]. |
| lon | Yes | Longitude in decimal degrees [-180, 180]. |
| mode | Yes | |
| area_m2 | Yes | |
| minutes | Yes | |
| polygon | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions output format and units, but does not state that the tool is read-only, nor discuss error conditions, performance, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, units, and example. It is front-loaded and contains no fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (context signal true), the description adequately explains the polygon output and units. It could mention coordinate system assumptions or empty-area behavior, but for typical usage it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (mode described), but the description adds units (decimal degrees for lat/lon, minutes, metres) and an example call. This compensates for missing schema descriptions and provides meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reachable-area polygon within a travel-time budget,' specifying the verb (compute) and resource (isochrone polygon). This distinguishes it from siblings like geocode, reverse_geocode, and catchment_pois, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a reachable area polygon is needed but does not explicitly contrast with siblings or provide when-not-to-use advice. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health-check tool.
Returns {"status": "ok"} so any MCP client can confirm reachability.
Example: ping() -> {"status": "ok"}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the exact output format and the health-check nature of the operation. It does not explicitly state 'no side effects,' but the minimal ping semantics make that reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line label, a return contract, and an example. There is no filler, and the most important information appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument reachability check with an output schema, this description is fully sufficient. It states what the tool does, what it returns, and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema already confirms an empty parameter object, so the schema description coverage is effectively 100%. Per the baseline for zero-parameter tools, a 4 is appropriate; no additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly identifies it as a health-check tool and gives the exact return payload, so an agent immediately knows its purpose. It is clearly distinguishable from the geospatial sibling tools by being a reachability probe rather than a geocoding/isochrone/POI operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that it is for 'any MCP client to confirm reachability,' which gives a clear usage context. It does not enumerate exclusions, but none are really needed because the tool takes no arguments and the sibling tools serve obviously different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reverse geocode a coordinate to a human-readable address.
Units: lat/lon in decimal degrees; returns a display-name string. Example: reverse_geocode(lat=3.15, lon=101.71) -> "Bukit Bintang, ..."
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It specifies units (decimal degrees) and return type (display-name string), but does not disclose limitations, error handling, or coordinate bounds. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences and an example convey all necessary information without wasted words. The structure is front-loaded with the purpose, followed by units and an illustrative example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, presence of an output schema (not shown), and sibling tools, the description fully covers what the agent needs: it explains input meaning, output type, and provides an example. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must add meaning. It provides units and a concrete example, which substantially clarifies the parameters' expected values. This compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reverse geocodes a coordinate to an address, using straightforward verb and resource. It distinguishes itself from the sibling tool 'geocode' (forward geocoding) by its name and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when converting lat/lon to a human-readable address, but does not explicitly state when to use it vs alternatives or exclusions. Given the sibling context, it's clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Composite reach score in [0, 1] for a single OOH site.
Combines gravity-weighted POI density, junction density, and category
diversity (public urban-analytics methodology). Returns the score plus an
auditable breakdown.
Units: lat/lon decimal degrees; minutes minutes; score unitless [0,1].
Example: site_reach_score(lat=3.15, lon=101.71, minutes=10, mode="walk")
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| mode | Yes | Routing mode for reachability/isochrone computation. | |
| minutes | Yes | ||
| weights | No | ||
| categories | No |
| Name | Required | Description |
|---|---|---|
| lat | Yes | Latitude in decimal degrees [-90, 90]. |
| lon | Yes | Longitude in decimal degrees [-180, 180]. |
| mode | Yes | |
| score | Yes | |
| minutes | Yes | |
| breakdown | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the methodology and that it returns a score with breakdown, but lacks details on data sources, performance, or side effects. Acceptable but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and front-loaded; every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main functionality and required parameters, but omits explanation of optional parameters (weights, categories) and error conditions. Output schema exists, so return structure is less critical, but input completeness could be better. Adequate for moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only mode has property-level description). Description adds value by explaining units and providing an example, but does not cover the optional parameters (weights, categories) or their semantics fully. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it computes a composite reach score for a single OOH site using gravity-weighted POI density, junction density, and category diversity. Differentiates from siblings like isochrone (generates isochrone), catchment_pois (returns POIs), and compare_sites (compares multiple sites).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0catchment_poiscompare_sitesgeocodeisochronepingreverse_geocodesite_reach_scoreScored across 7 tools
Each tool serves a distinct purpose: health check, forward/reverse geocoding, isochrone generation, POI query, and reach scoring/comparison. No two tools overlap in function, minimizing agent confusion.
Most tools follow a verb_noun or noun_phrase pattern (geocode, reverse_geocode, compare_sites). However, 'isochrone' and 'catchment_pois' are noun-oriented rather than verb-first, introducing slight inconsistency but still clear.
With 7 tools, the server covers a focused domain (location reachability analysis) without bloat. Each tool feels necessary, and the count is well within the 3–15 sweet spot.
The set provides a complete workflow: geocode, reverse geocode, compute isochrone, query POIs, score a site, and compare multiple sites. A minor gap is the lack of a tool to fetch POI details or handle transit-specific parameters, but core needs are met.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
Geospatial AI MCP server — satellite imagery, embeddings, weather, GNS governance
Canonical British Columbia Property Intelligence & Risk Screening MCP Server.
MCP server for Mireye Earth — federal-source-cited geospatial data for any MCP-aware agent.
