Skip to main content
Glama
urbankitstudio

UrbanKit County Parcel Atlas

by urbankitstudio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

@urbankitstudio/mcp-atlas

mcp-atlas MCP server Socket Badge

Query the verified parcel ArcGIS REST endpoints of 171 counties across all 50 US states (174 layers) for owner, APN and address lookup via the Model Context Protocol (MCP).

An MCP server that gives AI assistants direct access to UrbanKit Studio's atlas of manually verified county parcel GIS services. Ask Claude or Cursor to find the ArcGIS REST endpoint for any covered county, get the exact owner-search query URL, and look up parcel data — without needing to know anything about ArcGIS REST API conventions.

Coverage: 171 counties across all 50 US states, 174 verified endpoints (atlas 0.6.2).

Quick start

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "mcp-atlas": {
      "command": "npx",
      "args": ["-y", "@urbankitstudio/mcp-atlas"]
    }
  }
}

Cursor

Add to .cursor/mcp.json in your project root (or ~/.cursor/mcp.json globally):

{
  "mcpServers": {
    "mcp-atlas": {
      "command": "npx",
      "args": ["-y", "@urbankitstudio/mcp-atlas"]
    }
  }
}

Install globally (optional)

npm install -g @urbankitstudio/mcp-atlas

Then use mcp-atlas as the command instead of npx -y @urbankitstudio/mcp-atlas.

Related MCP server: Corridor-MCP

Tools

The four tools are one pipeline, and what separates them is how precisely you can already name the county:

You have

Use

You get

A state, or nothing

list_counties

Which counties are covered, and whether owner search works there. No URLs.

A vague, misspelled or FIPS reference

find_county

Every county that reference matches, named, each with its record

An exact state and county

get_parcel_endpoint

That one county's endpoint URL, layer, fields and sample query

A county and an owner's name

build_owner_query

A runnable URL that searches for that name

find_county and get_parcel_endpoint return the same per-county record. They differ in how you address the county: find_county accepts an uncertain reference and may come back with several candidates, get_parcel_endpoint takes an exact pair and answers about one. If you already know the county, skip find_county.

This server never executes a query and returns no parcel records. It tells you the URL to fetch; fetching it is yours to do.

list_counties

Browse coverage. Answers "is this county covered?" and "what can I search there?" — one line per county, with no endpoint URLs or field names.

Parameter

Type

Required

Description

state

string

No

Two-letter abbreviation (IL) or full name (Illinois)

Example prompt: "List all covered counties in Illinois"

Example output:

ST | County               | Slug                     | Coverage
--------------------------------------------------------------------
IL | Kane                 | kane-county              | owner+APN
IL | Cook                 | cook-county              | APN only
IL | DuPage               | dupage-county            | owner+APN
...

find_county

Resolves a reference you cannot state exactly. Fuzzy-matches a partial or misspelled name, a "County State" phrase, or a 5-digit FIPS code against every covered county, and names each county it matched so an ambiguous reference comes back as a list to choose from. Each match carries that county's record: endpoint URLs, searchable field names, owner field, sample query, license.

Parameter

Type

Required

Description

query

string

Yes

County name (Kane), name+state (Kane IL), or FIPS (17089)

Example prompt: "Find the parcel endpoint for Kane County Illinois"

get_parcel_endpoint

The default lookup once the county is known. Returns the full ArcGIS REST URL, layer index, searchable fields, owner field, a generic sample ?where=…&f=json query and the UrbanKit deep-link for one county. For a named owner, use build_owner_query rather than editing the sample query by hand.

Parameter

Type

Required

Description

state

string

Yes

Two-letter abbreviation or full name

county

string

Yes

County name (Kane or Kane County)

Example prompt: "Give me the ArcGIS REST endpoint for Cook County Illinois"

build_owner_query

The only tool that searches for a named owner. Fills a person or company name into the county's verified owner/taxpayer field as UPPER(field) LIKE UPPER('%NAME%'), a case-insensitive partial match, and returns a URL you can fetch or open. A county that publishes no owner name is refused here, with the reason, rather than handed a query that finds nothing.

Parameter

Type

Required

Description

state

string

Yes

Two-letter abbreviation or full name

county

string

Yes

County name

owner_name

string

Yes

Owner/taxpayer name (partial match)

Example prompt: "Build an ArcGIS query for properties owned by 'Smith' in Kane County IL"

Example output:

County:       Kane, Illinois
Owner field:  TaxName
WHERE clause: UPPER(TaxName) LIKE UPPER('%SMITH%')

Query URL:
https://gistech.countyofkane.org/arcgis/rest/services/KanePINList/MapServer/0/query
  ?where=UPPER(TaxName)%20LIKE%20UPPER('%25SMITH%25')
  &outFields=PIN,TaxName,SiteAddress,SiteCity,MailingAddress
  &returnGeometry=false&f=json&resultRecordCount=25

Example conversation

User: I'm doing due diligence on properties in Kane County, Illinois. Can you find all parcels owned by "Blackstone"?

Claude (using mcp-atlas):

  1. Calls get_parcel_endpoint → gets the gistech.countyofkane.org URL and confirms the owner field is TaxName

  2. Calls build_owner_query with owner_name=Blackstone → returns a ready fetch URL

  3. Optionally fetches the URL and formats the parcel results

Atlas coverage

The atlas is maintained by UrbanKit Studio. All endpoints are manually verified. Counties with an owner/taxpayer field support full name-based lookups; PIN-only counties support APN/parcel-number queries.

Full coverage map: https://urbankitstudio.com/parcel-atlas

Data

Atlas data is embedded in the package (no network calls at startup). The underlying @urbankitstudio/atlas SDK is also published separately for programmatic use.

What Socket flags, and how much of it is ours

Socket's supply-chain scanner rates this package in the mid-70s. Clicking through shows a long alert list. Each alert, checked rather than waved away:

Alert

Whose

What it is

usesEval

Not ours

No eval or new Function anywhere in src/. It comes from a dependency.

unmaintained (21)

Not ours

Transitive dependencies last published 2017–2021.

mixedLicense

Not ours

A dependency published as BSD-3-Clause AND ISC.

noTests

Ours, by design

files ships dist only. The suite lives in test/ and runs in CI. Shipping tests inside the tarball would be the defect.

networkAccess, filesystemAccess, envVars, shellAccess

Ours

An MCP server talks to a client over stdio and reads its own config. A server without these could not do the job.

unpopularPackage, noV1

Ours

Download count and a 0.x version. Both resolve with time, neither is a code issue.

Vulnerability and license both come back at 100, quality at 99. The number the badge shows is the supply-chain sub-score, and its single largest deduction is download count, a popularity measure wearing a security badge's clothes. Judge the list above, not the digit.

The four access alerts are what let the server read its own config and talk to a client over stdio, nothing more. It still never executes a query or returns a parcel record.

License

MIT — © 2026 UrbanKit Studio

Available Tools

4 tools
build_owner_queryBuild ArcGIS owner name query URLA

Constructs the exact ArcGIS REST query URL using that county's verified owner/taxpayer field. Returns a URL you can open in a browser or fetch directly. The query uses UPPER(field) LIKE UPPER('%NAME%') — case-insensitive partial match.

ParametersJSON Schema
NameRequiredDescriptionDefault
stateYesTwo-letter state abbreviation (e.g. 'IL') or full state name
countyYesCounty name (e.g. 'Kane' or 'Kane County')
owner_nameYesOwner/taxpayer name to search for (partial match, case-insensitive)

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It clearly discloses the query uses UPPER and LIKE for case-insensitive partial matching, and references a 'verified owner/taxpayer field' per county. This is sufficient to understand the tool's internal operation and side-effect-free nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states the action and result, second details the query mechanism. Every word is purposeful with no redundancy or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately covers what the tool does, how it works, and what it returns. It leverages the context of county-specific fields. For a URL builder with three well-documented parameters and no output schema, it is nearly complete; minor omission is potential limitations (e.g., URL length, ArcGIS version compatibility).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters have 100% schema coverage, but the description adds value by explaining the SQL-like query pattern (UPPER... LIKE) applied to owner_name, which goes beyond the schema's 'partial match, case-insensitive' description. This enhances understanding of how the parameter is used.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('constructs') and identifies the resource ('ArcGIS REST query URL'), clearly stating it builds the exact URL for owner name queries. It distinguishes from sibling tools (find_county, get_parcel_endpoint, list_counties) by focusing on URL construction for owner queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the tool returns a URL for browser or direct fetch, implying its use for querying by owner name. It also details the query pattern (case-insensitive partial match), giving guidance on behavior. However, it lacks explicit when-not-to-use or alternatives, though the context of siblings provides some differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_countyFind a county by name or FIPSA

Fuzzy-matches a county by name (e.g. 'Kane', 'Cook County', 'Cook County IL') or by 5-digit FIPS code. Returns endpoint URLs, searchable field names, owner field, sample query URL, and license info.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesCounty name, 'County Name State' (e.g. 'Kane IL'), or 5-digit FIPS code

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool performs fuzzy matching and returns specific data, which is transparent about its output. However, it does not disclose whether the tool is read-only, whether it requires authentication, or any other behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that efficiently conveys the purpose, input format, and return value. No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple lookup tool with one parameter and no output schema, the description is sufficiently complete. It explains the input and output clearly. However, it could be more complete by mentioning any prerequisites or common errors.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema coverage is 100%, so the schema documents the parameter 'query' with a description. The tool description adds value by providing examples and clarifying the fuzzy-matching behavior, which goes beyond the schema's static description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool performs fuzzy matching to find a county by name or FIPS code, and lists the specific information returned (endpoint URLs, fields, etc.). It distinguishes itself from siblings like list_counties by focusing on lookup rather than listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides usage examples and input formats (e.g., 'Kane IL', FIPS code), which helps the agent understand when and how to use it. However, it does not explicitly state when not to use it or compare to alternatives like list_counties.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_parcel_endpointGet parcel ArcGIS REST endpointA

Returns the full ArcGIS REST service URL, layer index, searchable field names, owner field, a ready sample ?where=…&f=json query, and the UrbanKit deep-link for a specific county.

ParametersJSON Schema
NameRequiredDescriptionDefault
stateYesTwo-letter state abbreviation (e.g. 'IL') or full state name
countyYesCounty name (e.g. 'Kane' or 'Kane County')

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must carry the burden. It lists what is returned but does not explicitly state that the tool is read-only or disclose any side effects, performance characteristics, or requirements. The description is adequate but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently enumerates all key outputs without redundancy. It is front-loaded and every element provides value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description adequately lists all expected return values. It could be strengthened by noting input validation or error handling, but is complete enough for a simple lookup tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with descriptions for both state and county. The description does not add additional meaning beyond what the schema provides, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific outputs: ArcGIS REST service URL, layer index, searchable field names, owner field, sample query, and UrbanKit deep-link for a county. It distinguishes from siblings like build_owner_query and find_county by focusing on endpoint retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a parcel endpoint for a specific county is needed, but does not explicitly state when not to use it or mention alternatives. Siblings (build_owner_query, find_county) suggest a workflow, but no direct guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_countiesList covered countiesA

Returns all counties in the UrbanKit Atlas that have a verified ArcGIS REST parcel endpoint. Pass a state abbreviation (e.g. 'IL') or state name (e.g. 'Illinois') to filter by state. Omit state to list all ~155 counties.

ParametersJSON Schema
NameRequiredDescriptionDefault
stateNoOptional: two-letter state abbreviation (e.g. 'IL') or full state name (e.g. 'Illinois')

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully carries the transparency burden. It discloses that only counties with verified endpoints are returned, and mentions the approximate count (155). No side effects or auth requirements are needed for a read-only list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first declares the main function, second explains the optional filter. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one optional parameter, no output schema, and no annotations, the description covers the tool's purpose, filtering, and scope. It could mention the return format (e.g., list of county names or IDs) but the core functionality is clear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%. The description adds value by clarifying that the 'state' parameter accepts both abbreviations and full names, and that omission lists all. This goes slightly beyond the schema's own description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns all counties in the UrbanKit Atlas with verified ArcGIS REST parcel endpoints. It uses a specific verb ('Returns') and distinguishes from siblings like 'find_county' and 'get_parcel_endpoint'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage instructions: pass a state abbreviation or name to filter, or omit to list all ~155 counties. It does not compare to sibling tools but implies when to use state filtering.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.1.0
    • First observedbuild_owner_query
    • First observedfind_county
    • First observedget_parcel_endpoint
    • First observedlist_counties
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 4 tools

Disambiguation2/5

find_county and get_parcel_endpoint overlap heavily: both return endpoint URLs, searchable fields, owner fields, and sample query URLs. list_counties and find_county also both identify counties, so the tool boundaries are not clearly distinct.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: list_counties, find_county, get_parcel_endpoint, build_owner_query. The action-object structure is predictable and easy to scan.

Tool Count4/5

Four tools is a reasonable size for a focused endpoint-discovery and query-construction service. However, the functional overlap between find_county and get_parcel_endpoint makes one of them nearly redundant.

Completeness4/5

The core workflow is covered: list available counties, resolve a county, get endpoint details, and build an owner query. Minor gaps remain, such as no direct execution of the built query and no builder for address- or PIN-based parcel searches, but these are arguably out of scope.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches