A worked MCP session
Every request and response below was made against the live server and is reproduced verbatim. The discovery tools need no key, so the calls can be repeated as printed. The MCP page describes the server; this one shows what it actually says, including what it says when a county cannot answer.
This is a recording, not an illustration. Every request and response below was made against the live server at https://urbankitstudio.com/api/mcp on 2026-08-17, and anyone can repeat them: the discovery tools need no key, so the commands work as printed.
It is here because an agent-facing API is easy to describe and hard to judge. What matters is not the tool list, it is what the server does when a county cannot answer, and that is the part a feature list never shows.
Opening the connection
The server speaks JSON-RPC over HTTP POST. A client opens with initialize:
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"transcript-capture","version":"1.0"}}}It answers in 252 ms with its protocol version, its name, and an instruction string the model reads before choosing anything:
{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-06-18","capabilities":{"tools":{}},"serverInfo":{"name":"urbankit-atlas","version":"0.3.0"},"instructions":"UrbanKit Studio MCP server. Six public tools query the parcel atlas (155 indexed U.S. counties across 50 states) and U.S. Census Geocoder without a key..."}}tools/list then returns eight tools. Six are free discovery (find_parcel_by_address, geocode_address, list_indexed_states, list_counties_in_state, find_county_by_fips, get_county_endpoint) and two are billable (enrich_address, radius_owners).
A county that answers
find_parcel_by_address for an address in Cook County, Illinois, answered in 580 ms:
{
"geocode": {
"matchedAddress": "121 N LA SALLE ST, CHICAGO, IL, 60602",
"countyFips": "17031",
"countyName": "Cook",
"lat": 41.883378835076,
"lon": -87.632333752582
},
"atlas_indexed": true,
"atlas_match": {
"county_slug": "cook-county",
"has_public_rest": true,
"verification": { "last_verified": "2026-05-15", "status": "live" },
"observed_health": {
"status": "ok",
"consecutive_failures": 0,
"last_ok_at": "2026-08-17T20:01:07.441+00:00"
},
"endpoints": [ { "url": "https://gis12.cookcountyil.gov/traditional/rest/services/CookViewer3Parcels/MapServer/0", "layer_name": "Parcels", "searchable_fields": [ { "name": "PIN10" } ] } ]
}
}The useful part is not the address match. It is that the response hands back the county's own REST endpoint and the fields that endpoint can be searched on, so the agent can go straight to the source rather than through this site. It also carries two different claims about health, deliberately: verification is when a human last checked the endpoint, observed_health is what the automated prober saw most recently.
A county that cannot answer
The same tool, same shape, for an address in Greenville County, South Carolina:
{
"geocode": { "matchedAddress": "301 UNIVERSITY RIDGE, GREENVILLE, SC, 29601", "countyFips": "45045" },
"atlas_indexed": true,
"atlas_match": {
"county_slug": "greenville-county",
"has_public_rest": true,
"verification": { "last_verified": "2026-05-15", "status": "live" },
"observed_health": {
"status": "down",
"consecutive_failures": 150,
"last_ok_at": "2026-08-04T12:01:45.862+00:00"
}
}
}This is the response worth reading twice. The county is indexed, it does publish a REST endpoint, and a human verified it in May. It has also failed 150 consecutive checks and last answered on the 4th of August, because the county's own ArcGIS service is currently stopped, which is not something this site can fix.
An agent gets all of that in one object. It can still take the endpoint URL and try, and it can also see that trying will probably fail and why. The alternative designs are worse in obvious ways: hiding the county pretends it does not exist, and returning it as healthy sends the agent into a timeout with no explanation.
A tool that refuses, and says what to do
enrich_address is billable. Called without a key it fails, and the failure is written for a reader who has to act on it:
Error: enrich_address requires an API key; the six discovery tools on this
server do not. Create or copy a key at https://urbankitstudio.com/account and
send it on the MCP HTTP request as Authorization: Bearer <key>. Hosted owner
lookup runs on paid plans (Starter $7/mo and up) or pay-as-you-go; plans at
https://urbankitstudio.com/pricing.It names the tool, says which tools do not need a key, gives the header to send, and links the two pages needed to continue. An agent can recover from that without a human. "Unauthorized" would have been correct and useless.
What this session does not show
The billable path is absent. Both paid tools need a key, and a transcript that included one would either leak it or be a fabrication, so what is recorded here stops where the key would start. The behaviour of those tools when a county cannot supply owner data is described on the [MCP page](/mcp) and measured on the [benchmarks page](/benchmarks) instead.
Timings are from one machine on one afternoon and are not a service level claim. Round trips here ran between 173 ms and 580 ms.
Tool descriptions change, and when they do the numbers on [agent evals](/agent-evals) expire, which is why that page records the exact descriptions its runs were scored against.
The build checks this page against the repository's MCP-SESSION.md on every deploy, and fails rather than publish a difference.