From answers to addresses: Grounding an LLM for location

Applications increasingly rely on language models to answer questions about the physical world: a good coffee shop near the office, whether a new restaurant is within a fifteen-minute walk, or how long the drive to the airport takes. A language model can answer these questions fluently from its training data. 

However, once an application needs to act on the answer – dropping a pin, drawing a route, or filtering locations by what is actually reachable – fluent prose is no longer sufficient. The application needs structured location data: an address, coordinates, routable points, and travel durations. 

This post examines how grounding an LLM in a purpose-built location source changes the quality of results for three common location tasks: place search, reachability, and travel time. The evaluation also compares cost and implementation tradeoffs between grounding with web search and grounding with Mapbox location APIs.

The short version: three capabilities

Grounding an LLM in a structured location source instead of (or alongside) the open web changes the output for three common location tasks:

1. Place search: Find places near a location or look them up by name, and receive a structured address and coordinate for every result instead of prose that must be parsed and geocoded. This task also provides the largest cost advantage.
2. Reachability: Ask whether a destination is within an N-minute walk or drive and receive an isochrone polygon that can be rendered or evaluated with point-in-polygon operations, rather than a straight-line estimate.
3. Travel time: Ask how long it takes to travel from A → B, or rank destinations by travel time, and receive an exact routed duration instead of an approximate value paraphrased from a web page.

Every measurement in this post comes from a reproducible evaluation using GPT-5.5, comparing identical prompts grounded in either open web search or Mapbox location APIs. The results are organized by capability – place search, reachability, and travel time – followed by cost comparisons, implementation examples, and guidance on when each approach is appropriate.

What grounding means

A language model learns from a large corpus of text. Many questions can be answered accurately from that learned knowledge, particularly when the information is stable over time.

Grounding extends the model by allowing it to retrieve information from an external source while generating a response. Rather than relying only on its training data, the model calls a tool, retrieves current information, and uses that information to produce the answer. This reduces hallucinations because the response is based on an authoritative data source instead of model memory. The language model still performs the tasks it does best – interpreting the request and generating natural language – but the underlying facts come from a system designed to maintain accurate, current location data.

Grounding is more than a direct API call. An API call retrieves data. Grounding combines data retrieval with language-model reasoning, allowing the model to determine what information to retrieve and how to incorporate it into the response.

1. Place search: The open web is written for people

Place search is one of the most common location tasks for AI assistants: "five coffee shops near Pike Place Market" or "the address of that restaurant." Mapping or routing applications require both a complete address and an accurate coordinate.

A model grounded in web search can often provide both. The challenge is determining where the coordinate originated. Web pages typically publish addresses but rarely include coordinates because coordinates are intended for machines, while web content is written primarily for people. As a result, the model either generates a coordinate from the address or extracts one from a third-party listing that appears to match the query. Neither approach is deterministic. Generated coordinates can drift away from the actual location, while matched listings may refer to a different business with a similar name. A purpose-built location source instead returns the address and coordinate together as a single structured record.

This limitation is systematic rather than occasional. When asked to report coordinates only when the original source explicitly provided them, web search returned coordinates for 38% of the 26-place evaluation set, compared with 100% before that constraint. Most coordinates had no identifiable source, while the remaining examples were frequently derived from hobbyist coordinate databases or outdated business directories. The limitation is not in the language model itself, but in the structure of the open web, where coordinates are rarely published as first-class data.

How reliable is the location each source returns?

To provide an independent comparison, the web-search results were evaluated against a neutral reference rather than Mapbox. Twenty-six locations with addresses confirmed by two independent databases were geocoded using the U.S. Census Bureau geocoder, and the distance between the official coordinate and the web-search coordinate was measured.

The evaluation found:

• The reported address matched the official record in approximately 65% of cases.
• The median coordinate error was approximately 270 meters.
• Eight of 26 results (31%) matched a different business with a similar name, placing the coordinate more than one kilometer away.

What the coordinate drift looks like

A median coordinate error of approximately 270 meters is easier to understand when visualized on a map. The example below compares the indexed location with the coordinate returned by web search for the same query. Although the address is correct, the returned coordinate is displaced by one city block.

What the model can act on

The point is not that one source is accurate and the other is not - on most questions, both are right more often than not. The point is that a structured location source hands the model a precise, typed, current address and coordinate in one call, or an honest gap, and that is the thing you build on. It is also the cheapest of the three tasks to ground this way: finding places near a spot ran 3.4× cheaper than web search, and looking a place up by name 6.4× - the cost table below has the full breakdown.

2. Reachability: "Within a 15-minute walk" is a polygon, not a guess

Reachability answers a common location question: is a destination within a fifteen-minute walk or a ten-minute drive? A model grounded in web search can often provide a plausible answer by estimating the distance between two locations. However, those estimates are typically based on straight-line distance rather than the actual transportation network. Straight-line estimates ignore rivers, highways, one-way streets, and other constraints that determine how people actually travel.

A purpose-built location source computes reachability from the underlying road and path network. Instead of returning only a yes-or-no answer, it returns an isochrone – a polygon representing every location reachable within the specified travel time.

Same answer, but Mapbox's is a renderable/geofenceable polygon, not an estimate. The structure is the value, not the verdict. That is the difference that matters when you are building: web search can often land the same yes/no, but a polygon is a thing your app can do something with - render it, geofence against it, test a hundred candidate places against it at once. A reachability polygon is a field web search never returns; the model would have to invent it.

When the structure changes the answer

In Seattle both sources agreed. They do not always. Take two ordinary addresses in Milwaukee - 1100 West National Avenue and 1100 West Canal Street - about 890 meters apart in a straight line. Nothing in the addresses hints that the Menomonee Valley - an active rail corridor and river with no pedestrian crossing between the two points - runs between them. Ask whether one is a fifteen-minute walk from the other:

Web search was not unlucky here; it is unstable. Across 18 runs it answered “yes, about 12 to 14 minutes” half the time, reasoning from raw proximity because no page documents this particular walk. The isochrone follows the real foot network and puts the destination outside the fifteen-minute contour every time. That is the point of grounding: not that web search is always wrong, but that a location source is right deterministically, exactly where a confident guess fails.

On cost this task is closer than place search. With the geometry fused server-side - the tool geocodes, runs the isochrone, and tests the point, returning only the verdict - a reachability check ran 4.2× cheaper than web search. The polygon itself never enters the model's context, which is what keeps the token count down.

3. Travel time: An exact number, and a current one

The third task is travel time: how long it takes to travel from A to B, or which destination is closest. This is the task where web search looks most competitive. For well-known places, it often returns a sensible travel estimate from a route page and correctly orders candidates more often than not. However, it cannot return an exact duration that applications can compute on or account for current road conditions. A location source answers from a routing matrix instead, returning an exact duration in seconds computed on the road network. With the driving-traffic profile enabled, travel times reflect current traffic conditions.

Two points are worth noting. First, the Mapbox result is a driving-traffic time computed from current conditions, reflecting traffic speeds, incidents, and road closures at the time of the request. As conditions change throughout the day, the returned travel time changes as well. Web search, by comparison, returns a static estimate from a published page rather than a route computed from current conditions.

Second, in the ranking example, both methods produce the correct order. The difference is the returned values. Mapbox provides exact, sortable travel times from a single routing call, while web search assembles approximate travel times from multiple sources, including transit blogs, marketing pages, and PDFs. In this example, the Empire State Building estimate from web search is five minutes shorter than the routed travel time because it comes from the building's published visitor information rather than a routing calculation.

What it costs, across all three

To use a web page, the model takes the whole page into its context as input tokens. Even if only a small portion of the page contains the relevant information, the model still processes the surrounding content. A purpose-built location source returns a compact, structured record instead. The same information is delivered in a much smaller payload. The example below shows the input the model receives for the query, "Find 10 coffee shops near Pike Place Market in Seattle with addresses.

Across all four tasks, several page reads collapse into one structured call and the cost follows. Web search input is almost entirely retrieved page text: a 34-token question reaches the model as roughly 8,700 billed input tokens once search content is attached, against a few hundred for a structured record. Measured across the four tasks, that is 13× to 31× fewer input tokens and 3.4× to 6.4× lower end-to-end cost. The gap is widest on the two geometry tasks. There the tool runs the isochrone or matrix server-side and returns only the verdict, so the polygon never enters the model’s context.

Web search bills on two lines at once: $10 per 1,000 calls, plus the retrieved content at the model’s input rate. One configuration, the preview tool on non-reasoning models, supplies content for free but lists at $25 per 1,000 calls. That fee alone exceeds the cost of any complete Mapbox query in the table. Measured end-to-end on gpt-4.1, the free-content configuration still ran about 3–6× the cost of the same tasks grounded through Mapbox.

One important behavioral difference is that providing a model with a web_search tool does not guarantee that it will use it. On some travel-time queries, the model answered from memory instead of performing a web search. Those responses are less expensive but are not grounded. When the model does use web search, as in the queries measured here, each search incurs both the per-search fee and the additional page tokens.

Fractions of a cent per query may appear insignificant, but they accumulate at production scale. Web search also carries a flat per-search fee in addition to token costs - $10 per 1,000 searches at list price. A query that performs three searches incurs approximately $0.03 in search fees before accounting for input tokens. At production volume, that fee becomes a measurable component of inference cost. How much any of this matters depends on your traffic and your margins - that cost-benefit call is yours to make, which is why every figure here comes from a run you can repeat with your own numbers.

The code is the same shape

Wiring either source up looks almost identical. The model is provided with a tool and invokes it as needed. The examples below compare a model using web search with a model grounded through the Mapbox hosted MCP server, restricted to the two search tools required for this query: one to geocode the landmark and one to search for nearby places in the requested category. Authentication uses a Mapbox access token passed as a Bearer token, with no infrastructure to deploy.

LLM + web search

import { Agent, run, webSearchTool } from "@openai/agents";

const agent = new Agent({
  name: "web-search",
  model: "gpt-5.5",
  instructions: "Answer the question. Use web_search for current info. Cite sources.",
  tools: [webSearchTool()],
});

const result = await run(agent, "5 coffee shops near Pike Place Market, with addresses");

LLM + Mapbox

import { Agent, run, hostedMcpTool } from "@openai/agents";

const mapbox = hostedMcpTool({
  serverLabel: "mapbox",
  serverUrl: "https://mcp.mapbox.com/mcp",
  authorization: process.env.MAPBOX_TOKEN, // a Mapbox access token, sent as Bearer
  allowedTools: ["search_and_geocode_tool", "category_search_tool"],
  requireApproval: "never",
});

const agent = new Agent({
  name: "mapbox-search",
  model: "gpt-5.5",
  instructions: "Answer location questions only from the Mapbox tools. To find a " +
    "category of place near a landmark, geocode the landmark first, then " +
    "category-search that category around the point. Give addresses and coordinates.",
  tools: [mapbox],
});

const result = await run(agent, "5 coffee shops near Pike Place Market, with addresses");

The effort is the same. The difference is what comes back: prose the model paraphrases, or structured fields the model, and your code, can use directly. The same server exposes isochrones and the travel-time matrix as sibling tools when you need the other two capabilities; a hand-rolled version of the search tool, for anyone who wants the explicit steps, ships in the companion repo.

When to use which

These approaches are complementary rather than competing, and the right choice depends on the task. Structured location data is designed to return coordinates, polygons, and routed travel times, while the open web is not. The comparison reflects those different design goals. The more interesting question is how each approach performs across the three tasks evaluated here.

• Place lookup and nearby search. This is where the structured source wins most clearly, and on two axes at once: it returns the typed address and coordinates the open web does not carry, and it does so 3.4–6.4× cheaper because one structured call replaces several page reads. Reach for grounding here by default.

• Travel-time queries. The most nuanced answer: for well-known places web search lands a sensible typical figure and usually the right ordering. But it cannot see live traffic, and - left to its own devices - it may answer from memory without searching at all, so you cannot even be sure it grounded. The structured source gives an exact, sortable number, and with the driving-traffic profile a current-conditions drive time - reflecting real speeds, incidents, and closures - that the model otherwise can’t get. Use it when you need a value your code can compute on, or a number that reflects the road right now; web search is a reasonable fallback when an approximate, static answer will do.

• Reachability. If all you want is a yes/no for one famous pair of places, web search often gets there. If you need the answer as something your app can render, geofence, or test many candidates against, only the structured source returns the polygon - web search would have to fabricate it.

Web search keeps the advantages it is built for: breadth, news, the open-web long tail, anything that lives on a page somewhere. And there is a class of question this post has deliberately left out - the expanded query. "Best taco spots in town." "A proper dive bar with live music." A structured index is honest to a fault here: superlatives and vibes are not fields it carries, because that knowledge lives in reviews, listicles, and local writing on the open web. The pattern that answers those is the two sources working in sequence - web search expands the query and discovers the candidates, then the location source grounds each one, attaching the address, coordinates, reachability, and travel times your app needs to act on it. This post is the first in a series; the next one builds that pipeline and puts numbers on it.

This layer is also model-agnostic. Grounding does not replace a great language model; it gives one great inputs. The better the model, the more it gets right with a clean, current source underneath it.

See it for yourself

Every number here comes from a run you can reproduce. The companion kit - runnable scripts on GitHub, one per claim - does each comparison with your own keys: the token-tax receipt and the coordinate-provenance, coordinate-drift, and typed-fields probes for place search; the isochrone reachability check and the Milwaukee verdict-flip; the driving-traffic and ranking travel-time runs; and the full per-task cost benchmark, with the result files behind every figure. The README also documents how each case was found. Run them and check the work.

Method notes, and where we could be wrong

Location reliability. The web column in the place-search table is scored against the U.S. Census Bureau geocoder (benchmark Public_AR_Current) on the 26 found places whose on-record address two independent databases agree on. Census coordinates are street-interpolated, not rooftop - tens of meters of noise - so the threshold is 500 m, wide enough that the reference noise cannot fake a pass. The Mapbox column is deliberately textual: its address and coordinate are the indexed record itself, and scoring that by place name measures name collisions, not accuracy.

Reachability and travel time. The routing rows are single worked cases from a live capability run, shown to illustrate the shape of each answer, not a large sample. The travel-time caveats are real and stated in the table: a driving-traffic duration is a live snapshot of current conditions, so it changes through the day, and on the ranking case both sources order the places correctly - the Mapbox edge is the exact, sortable per-leg minutes, not the ordering.

Variance and cost basis. Web search may run one search or several, or none: in the travel-time capability baseline, where the model chose freely, it searched in only a third of runs and answered the rest from memory. In the cost-table runs it searched once per query, so those comparisons are like for like. Web search is billed at $10 per 1,000 calls plus retrieved content at the model’s input rate; the token figures here are the billed counts the API reports. Cost figures are medians of three benchmark passes, three reps each, at published list prices plus per-call fees, on gpt-5.5. The two geometry rows use fused tools that geocode and run the isochrone or matrix server-side, returning a compact verdict, so the polygon never enters the model’s context.

Build with Location AI

Whether you're building AI agents, AI-native applications, or adding location intelligence to an existing product, check out the Mapbox Location AI getting started guides and try the companion benchmarks with your own data. If you'd like to discuss your use case, explore architectural approaches, or build together, contact the Mapbox team.