Overview
A reverse geocoding API for US and Canadian coordinates. Reverse Geocode works by converting the latitude and longitude coordinates into a human-readable address. Only supports USA and Canada Coordinates. It uses advanced algorithms and a large database of locations to provide accurate and up-to-date information.
Live Test Reverse Geocoding Grounding Data Source →
The tool
Once your client is connected to the VerveContext server, this appears in its tool list as ReverseGeocodingGroundingData. It is read-only and open-world — it fetches and never mutates anything on your side — so most clients call it without asking you to confirm.
{
"name": "ReverseGeocodingGroundingData",
"arguments": {
"lat": "40.714224",
"lon": "-73.961452"
}
}You do not name the tool yourself; the model picks it. Asking about 40.714224 in the terms this source covers is enough for it to reach for ReverseGeocodingGroundingData on its own — naming it explicitly also works, and is the way to force the call.
Connecting
One server URL covers every source in the catalog, including this one. Authorization is OAuth: the client opens a browser once, and there is no key to paste into a config file.
{
"mcpServers": {
"vervecontext": {
"url": "https://api.vervecontext.com/v1/mcp"
}
}
}https://api.vervecontext.com/v1/mcpPer-client setup — Claude, Cursor, VS Code, ChatGPT — is on the MCP setup page.
Arguments
These are the properties on the tool's inputSchema, so a well-behaved client validates them before the call is made. Premium arguments are accepted on every plan but only take effect on plans that include them.
| Argument | Type | Description |
|---|---|---|
latRequired | number | The latitude of the coordinates range -90–90 |
lonRequired | number | The longitude of the coordinates range -180–180 |
What the model gets back
The result carries a structuredContent object matching the tool's declared outputSchema, so a client reads fields without parsing prose. status is "ok" and error is null on success; a null field means the value was not available for that input, not that the call failed.
{
"status": "ok",
"error": null,
"data": {
"zipcode": "11211",
"state_abbr": "NY",
"city": "Brooklyn",
"state": "New York",
"distance": 0.6501757300758664,
"latitudeClosest": "40.712090",
"longitudeClosest": "-73.95427",
"countryCode": "US",
"latitude": 40.714224,
"longitude": -73.961452,
"estimatedCity": true,
"nearestCities": [
"Brooklyn",
"Brooklyn Park",
"East Brooklyn",
"Brooklyn Center",
"Brooklyn Heights"
]
}
}
Response fields
Paths are relative to data. Premium fields are absent rather than zeroed on plans that do not include them, so check for presence instead of comparing to 0.
| Field | Type | Example | Description |
|---|---|---|---|
zipcode | string | 11211 | ZIP code for the location |
state_abbr | string | NY | Two-letter state abbreviation code |
city | string | Brooklyn | Primary city name at coordinates |
state | string | New York | Full state name |
distancePremium | number | 0.6501757300758664 | Distance to closest coordinates in miles |
latitudeClosestPremium | string | 40.712090 | Latitude of closest mapped coordinate |
longitudeClosestPremium | string | -73.95427 | Longitude of closest mapped coordinate |
countryCode | string | US | ISO country code for location |
latitude | number | 40.714224 | Input latitude coordinate |
longitude | number | -73.961452 | Input longitude coordinate |
estimatedCityPremium | boolean | true | Whether city is estimated or exact match |
nearestCitiesPremium | array | ["Brooklyn","Brooklyn Park","East Brooklyn"] | List of nearby cities ordered by proximity |
Why ground on it
A model can produce something that looks like this answer from its training data, and be confidently out of date or simply wrong. This source returns the current value in a shape you can check, which is the difference between an answer you can cite and one you have to hedge.
Point an evaluation at zipcode: it is the field most worth pinning a claim to, and it is either present and current or absent — never plausibly invented.
Failure modes
Errors come back as tool errors carrying a sentence the model can act on, not a bare status code. Error handling covers the full list.
| Status | What it means |
|---|---|
400 / 422 | The arguments did not validate. The message names the offending one. |
401 | The OAuth session is invalid or expired — reconnect the server. |
403 | Blocked by a key restriction or an IP allow-list. Never a bad identity. |
404 | This source is not part of VerveContext. Check the catalog. |
429 | Out of credits, or a brief rate limit. The message tells them apart. |
A call costs 6 credits each time the tool actually runs; a model that reasons about the tool without calling it costs nothing.
Use cases
- Fleet Telematics Tracking
- Logistics systems match vehicle GPS pings against city and state boundaries to generate human-readable trip summaries for dispatchers.
- Mobile Photo Geotagging
- Camera apps read coordinate metadata from uploaded photos to display the city and state where each picture was taken.
- Delivery Address Autofill
- When a customer shares device coordinates at checkout, ecommerce apps automatically populate the city, state, and ZIP code fields.
- Field Service Dispatch
- To assign incoming repair tickets, maintenance platforms convert technician coordinates into local municipality names and postal codes.
Other ways to use Reverse Geocoding Grounding Data
Set up Reverse Geocoding Grounding Data on VerveContext, or reach the same source a different way. Your VerveContext account and credits work on all of them — one key, one balance.
Related
More in Geography: