Why we built PlaceRoot

An agent asks a simple spatial question — "what's within 500 meters of this point?" — and, with a typical map API, the answer comes back as a GeoJSON FeatureCollection. Every feature carries a full geometry, a nested sources array with per-property provenance and confidence, a names struct, a categories struct, contact fields, and more. Multiply that by a few hundred features, a normal count for a dense downtown block, and the response no longer fits in a reasonable slice of a context window. The agent either truncates blindly, burns most of its budget on one tool call, or the integration just doesn't ship.

That's the payload half of the problem, and it's well enough known now to have a name in public, from a company that ships production geospatial infrastructure: Mapbox's "GeoAI in 2026" post calls large geospatial payloads the biggest challenge for MCP-based mapping integrations. A Geoawesome essay from June 2026 puts a number on the shape of it: a real-world GeoJSON payload of roughly 45,000 tokens collapses to about 25 tokens once you return a reference instead of the geometry itself. That gap is most map tooling's original sin — it was built for GIS software and browsers, which have no token budget, not for a model that does.

The other half is quieter and, for an agent, more dangerous: it isn't a data problem so much as a confidence problem. Ask a model where the nearest coffee shop to a given address is, or which of three cities named Cambridge a landmark sits in, and it will answer — fluently, specifically, and with no signal to the caller that it's guessing. A language model's spatial knowledge is frozen at training time and was never grounded in a coordinate system to begin with; it knows the Eiffel Tower is a famous landmark in Paris because that sentence appeared enough times in its training data, not because it consulted a map. Ask it something that wasn't in the training data — which businesses are open on this block right now — and it will still answer, just as fluently, and just as wrong.

Two structural camps

Look at what's available today for grounding an agent in map data, and it splits into two camps, each solving a different half of the problem and ignoring the other.

The first camp is vendor-keyed APIs. You get an API key, you get billing, and in exchange you get curated, often well-ranked place data — sometimes even AI-generated summaries. This solves the payload problem reasonably well, because the vendor controls the response shape. What it doesn't solve is the dependency: your agent's map grounding now lives behind a signup flow, a metered price per call, and someone else's terms of service on caching and training. One current example: Google's Maps Grounding Lite is priced at $14–25 per 1,000 prompts, with no-caching and no-training terms attached — a cost structure built for a per-seat SaaS product, not for an agent that might fire off a hundred spatial lookups planning a single trip.

The second camp is open-data wrappers, most commonly built on OpenStreetMap via Nominatim or Overpass. These are keyless, which solves the dependency problem — but most of them are thin passthroughs: you get raw OSM tags or raw GeoJSON back, at whatever size the underlying query produces. The payload problem is unsolved, just moved from a paid API to a free one. You've traded a metered key for a token budget that blows up on any moderately dense area.

Neither camp treats "fits in an agent's context window" as a first-class design constraint, and neither treats "what the model already knows" as an input worth asking for. A vendor API takes a query string and returns whatever it returns; it has no field for "the agent already knows this is near the Space Needle, it just needs to know what's there." An open-data wrapper takes the same query string and returns even more of it, unfiltered. Both leave the actual division of labor — the model knows the world, the map knows the data — unaddressed, and the caller pays for that omission in tokens, in dollars, or in a wrong answer stated as fact.

The seam

PlaceRoot queries Overture Maps' public GeoParquet release directly with DuckDB — no API key, no signup, no intermediate database, no ETL job. Row-group pushdown on the bbox columns means a query only reads the tiles it needs. That gets the right data quickly. It doesn't, by itself, make the data small — a raw Overture Places record still serializes to a few hundred tokens per feature once you include the nested sources, categories, names, and address structs. Making the payload problem disappear is a separate design rule, applied to every tool: return an answer, not a data dump. Every response is built to a token budget of roughly 2,000 tokens, and when a result would exceed it, rows are dropped nearest-first-preserved and optional fields stripped, with truncated: true and an explicit omitted_count rather than a silent cut. Measured against the committed benchmark fixtures: summarize_area answers a "what's in this area" question in 113 tokens; find_places returning ten ranked, deduplicated coffee shops within a kilometer comes back at 702 tokens. Registering all 29 tools costs 13,438 tokens of schema surface before a single question is asked — that's the other cost, paid once per conversation whether or not the agent ever calls anything, and it's roughly 103 median answers' worth. An install that only needs geocoding and place search can load a narrower tool profile instead and cut that same surface by more than half.

The confidence problem gets its own fix, and it's a narrower one than it sounds: separate what the model knows from what needs to be looked up, and say so in the tool's own instructions. PlaceRoot's server instructions put this plainly — "You know things it cannot: that 'san jose airport' means San Jose, California, that the Eiffel Tower is in Paris. This server knows only what exists at which coordinates in the current Overture release." A caller that sends one combined string — "coffee near the space needle" as a single search term — forces the server to guess which words are the place and which are the thing being looked for, guessing from map data alone, where a fragment like "san" names a division in Henan as readily as a city in California. Passing the location separately (a city name, or coordinates when the agent already has them) means a wrong hint costs a retry, never a wrong answer — every row still comes from the data, not from a guess about what the query string meant.

Surviving how people actually type

None of this is theoretical, because none of it stays fixed on its own. A 148-question corpus, run cold — fresh process, empty cache, every query — across 40-plus cities is what actually exercises it, and a second sweep of 24 fresh phrasings the way people actually type ("coffe," "seatle," "farmacy," "stuff to eat near the space needle," "the bean chicago") turned up five failures with four distinct causes, each now a fix and a regression test:

• "notre dame paris" landed in Indiana. A length-preference rule favored the two-token candidate unconditionally, and an 8,000-person Indiana CDP beat Paris's 2.1 million. Length now only wins between comparably prominent places — no small town outranks a world city on word count alone.
• "harvard square cambridge" lost to the wrong Cambridge — twice over. The right answer sits in the third city named Cambridge (UK, then Ontario, then Massachusetts), so sequential retries never reached it. Ambiguous names now search their next namesakes too, all at once, in a query shaped to keep each city's row-group pruning intact — an early draft that OR-ed the per-city filters together took 73.8 seconds; keeping the branches separate brought it to 8.9.
• "hoover dam" came back empty, with the actual dam 200 meters from the search hint. A gate meant to skip redundant scans was counting hits from anywhere as coverage — and "hoover dam" anchors on Hoover, Alabama, where a wildcard scan for "dam" turns up a person named Adam Cox and a church called Damascus Baptist. The gate now only counts hits near the reference point.
• "plaza mayor madrid" matched a plaza 25 kilometers out. The ranking had no distance term to fall back on when no administrative division matched the query outright. It does now.

The corpus methodology has one rule behind all of it: a fast wrong answer scores as a win unless something actually checks the answer. The clearest example on record is a plain geocode lookup — asking for "Casablanca" once returned coordinates in Chile, in 0.2 seconds, faster and more confident-looking than the correct answer would have been. Cold latency without a correctness check would have called that a success. With the fix and the regression test in place, the corpus runs 24 of 24 correct — up from 19 — with every single tool call answering cold, from an empty cache, in 4.6 to 9.8 seconds.

What it doesn't do

Some honest limits, not smoothed over:

• The data has a vintage. Every answer comes from one pinned Overture Maps release, not a live feed. There's no traffic model, no live opening hours, no ratings or reviews, and distance_matrix is straight-line haversine, not road-network travel time. Anyone who needs those specifically should reach for a live vendor API instead — that comparison is the honest framing, not a reason to pretend the gap isn't there.
• Overture's places data leans toward businesses. It's derived largely from business listings, which makes it strong on shops, restaurants and clinics and thin on the places a family actually goes on a Saturday — playgrounds, neighborhood parks, dog parks. Those aren't missing from Overture, they're in a different theme (base, the OpenStreetMap conflation), and PlaceRoot's places tools query it too by default — it roughly 2.5x's playground coverage in one measured city — but the fix is a second dataset scan, not a fully solved bias.
• No hosted tier yet. PlaceRoot runs as a local or self-hosted process. --http mode exists and works, but it's your process, your TLS termination, your reverse proxy — nothing here is a managed no-setup endpoint you point a client at today.
• Routing is walking-first. The routing stack builds its own graph from Overture's transportation theme rather than depending on a hosted routing service. Drive and cycle modes exist and pass the same regression tests, but pedestrian routing and isochrones are where the stack has been exercised hardest.
• The corpus is real but not exhaustive. 148 questions across 40-plus cities and a 24-question adversarial sweep catch real failure modes, and each fix ships with a regression test so it can't silently regress — but a corpus this size cannot claim to have found every ambiguous name or every malformed query a person will actually type. The next honest step is a harder set, not a victory lap.

Try it

The whole install is one block of JSON and no account:

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

Or run it directly with uvx placeroot. Source, the full tool catalog, and the design rules behind them: github.com/chuofringer/placeroot. The numbers in this piece come from docs/benchmarks.md and the query corpus in benchmarks/ — regenerated from the code, never hand-edited.