PlaceRoot

Ground AI agents in open map data.

PlaceRoot is an MCP server that answers spatial questions from Overture Maps — no API key, no signup, no vendor platform.

• Answers, not data dumps. Every tool returns compact, ranked results sized for an agent's context window — never a raw GeoJSON dump.
• Rich, filterable place data. Category, brand, confidence, operating status, contactability — all queryable, sourced from Overture's open dataset (contributed by Meta, Uber, TomTom, and others).
• Boundary-accurate. Search inside a named place's real administrative polygon, not just a guessed radius circle.
• Zero setup. Reads Overture's public data directly — nothing to install beyond the server itself, no key, no database.

Why PlaceRoot

It is the only keyless MCP server that does real graph routing over global open map data. isochrone and route walk an actual street graph built from Overture's transportation segments — not a straight-line approximation — anywhere on Earth, with no key, no signup, and no per-call quota. All 28 tools work that way.

Every one of those 28 tools declares MCP annotations — closed-world, plus a human-readable title, and readOnlyHint: true on the 27 that are pure lookups — so a client can tell before it prompts you which calls touch nothing. The one exception is honest about itself: render_map writes an HTML file, so it declares readOnlyHint: false. Keyless and annotated is a combination the field mostly hasn't shipped. Honest caveat: Claude Code does not gate its permission prompts on readOnlyHint (it uses its own classifier), so the practical win is with clients that do, such as Codex CLI and Copilot-class agents — plus spec hygiene everywhere else.

What it deliberately does not do, because Overture's open data does not carry it:

• No live traffic. Routing is free-flow; durations do not reflect current conditions.
• No opening hours. Places carry categories, brands and contacts, not schedules.
• No ratings or photos. There is no review corpus and no imagery behind these answers.

If a question needs one of those three, a commercial maps API is the right tool. For where things are, what is around them, and what is reachable from them, PlaceRoot answers without a key.

Quick start

Add to Claude Desktop / Claude Code:

{
  "mcpServers": {
    "placeroot": {
      "command": "uvx",
      "args": ["placeroot"]
    }
  }
}

(npx placeroot also works, if you'd rather use the npm launcher: set "command": "npx".)

Or run it directly:

uvx placeroot             # stdio MCP server
uvx placeroot --http      # HTTP endpoint at http://127.0.0.1:8321/mcp

What it can do

28 tools, all returning compact, budgeted answers. Several single-item tools have a *_batch sibling that collapses many calls into one round-trip.

Workflow prompts

Three MCP prompts ship with the server: canned multi-tool workflows that encode which tool to call first, what to do with its output, and what the answer should look like. In Claude Code they appear as slash commands; Claude Desktop and Cursor surface them in their own prompt pickers.

/mcp__placeroot__site_selection bike repair shop | Portland, Oregon

Prompts cost zero tokens in tools/list — a client fetches them only on prompts/list, and only materializes one when you invoke it. A test asserts tools/list is byte-identical with and without them registered, so adding a workflow here can never grow the context every conversation pays for.

They are also registered under every PLACEROOT_TOOLS selection, including subsets that drop tools a prompt names — a workflow is still worth reading when one step is unavailable, and it costs a subset install nothing. When the active selection excludes a referenced tool, the rendered prompt ends with a note naming it and telling the agent to route around the gap rather than to attempt a call that would fail.

Resources

Two MCP resources expose the server's argument-free lookups as attachable context, so you can pin them into a conversation without spending a tool call:

In Claude Code they auto-complete as @-mentions:

@placeroot:placeroot://data-version
@placeroot:placeroot://categories

Claude Desktop and Cursor list them in their own attachment pickers.

Like prompts, resources are registered under every PLACEROOT_TOOLS selection: they never appear in tools/list, so gating them would save a subset install nothing. A test asserts tools/list is byte-identical with and without them registered.

Loading fewer tools (PLACEROOT_TOOLS)

All 28 tool schemas cost roughly 12.2k tokens of every conversation's context, paid before the agent asks anything — about the cost of 93 median answers. Most installs use a slice of that surface, so PLACEROOT_TOOLS selects which tools get registered. Unselected tools are never registered and never appear in tools/list.

{
  "mcpServers": {
    "placeroot": {
      "command": "uvx",
      "args": ["placeroot"],
      "env": { "PLACEROOT_TOOLS": "core" }
    }
  }
}

The value is a comma-separated list of profile names, tool names, or both — the union of everything named:

• core — find_places, geocode, reverse_geocode, place_details, resolve_place, search_categories, summarize_area, route, places_along_route. The single-purpose tools that answer most spatial questions; no batch siblings, no buildings/land-use, no rendering. search_categories is in for its own reason: find_places' category filter takes Overture taxonomy slugs, and a wrong slug comes back as zero results plus a note to look the slug up — a dead end without the lookup tool to call.
• search — the find/name/identify family: find_places, place_details, geocode, resolve_place, reverse_geocode, their *_batch siblings, address_at, search_categories, and gers_lookup.
• routing — route, isochrone, distance_matrix, within_distance, optimize_route.
• analysis — summarize_area, summarize_buildings, compare_areas, buildings_at, land_use_at, infrastructure_at, water_near, admin_lookup.
• geometry — simplify_geometry, render_map.

data_version is registered under every profile: it is ~230 tokens and the only way an agent can tell which Overture release backs its answers.

Profiles may overlap, and a list may mix them with bare tool names — PLACEROOT_TOOLS=routing,find_places or PLACEROOT_TOOLS=find_places,geocode,route. A name that is neither a profile nor a tool fails at startup with the list of valid names, rather than quietly falling back to loading everything. The server logs one line at startup naming what it registered (registered 10 of 28 tools (PLACEROOT_TOOLS=core)), so a selection that didn't apply — an empty value, a variable that never reached the process — is visible rather than silently the full 28.

Design notes

Agents are bad at maps. Existing map tools either require vendor API keys or return payloads far too large for a context window. PlaceRoot's rule: every answer fits in a couple of thousand tokens, and anything bigger comes back as a summary.

A few things that set it apart:

• Stable place ids. Every place carries its Overture GERS id, so an agent can hold onto a place across turns and look it up again later instead of re-searching.
• Built-in geocoding. Place-name lookup works out of the box — no third-party geocoding service involved.
• Fast repeat queries. Frequently used data is cached locally, so repeat questions answer in milliseconds and keep working offline.
• Self-hostable end to end. Run it locally, serve it over HTTP, or point it at your own copy of the data — no dependency on anyone else's service.

Development

uv sync           # install dev dependencies
uv run pytest     # offline test suite
uv run ruff check .

Docs

• ROADMAP.md — where this is going · PLAN.md — product plan and positioning
• docs/benchmarks.md — token efficiency: per-answer cost, and the schema surface it's paid against
• docs/PUBLISHING.md — how releases reach PyPI + npm
• docs/WEBSITE.md — the marketing site: serve locally and deploy
• docs/MIRROR.md · docs/METRICS.md · docs/launch/

License

MIT