A
licenseNot graded
qualityC
maintenanceSt. Louis County GIS — St. Louis County, Missouri open geospatial data (ArcGIS). Enables searching and querying datasets like parcels, addresses, zoning and public works.
16
MIT
UrbanKit County Parcel Atlas
by LEOyrh
This server provides access to a manually verified atlas of 150+ US county parcel ArcGIS REST endpoints, enabling property owner and parcel lookups without requiring knowledge of ArcGIS REST API conventions.
List covered counties: Retrieve all counties in the atlas with a verified ArcGIS REST parcel endpoint, optionally filtered by state (two-letter abbreviation or full name), showing coverage type (owner+APN or APN only).
Find a county by name or FIPS code: Fuzzy-search by county name (e.g.,
Kane,Cook County IL) or 5-digit FIPS code, returning endpoint URLs, searchable field names, owner field, a sample query URL, and license info.Get a county's parcel endpoint: Retrieve the full ArcGIS REST service URL, layer index, searchable fields, owner field, and a ready-to-use sample
?where=…&f=jsonquery for a specific county.Build an owner name query URL: Construct a precise ArcGIS REST query URL to search parcels by owner/taxpayer name using a case-insensitive partial match (
UPPER(field) LIKE UPPER('%NAME%')), returning a URL ready to fetch directly.
Provides tools to query US county parcel data from ArcGIS REST endpoints, including listing covered counties, finding county endpoints, and constructing owner queries.
@urbankitstudio/mcp-atlas
Query 155 verified US county parcel ArcGIS REST endpoints 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: 155 counties across all 50 US states.
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-atlasThen use mcp-atlas as the command instead of npx -y @urbankitstudio/mcp-atlas.
Related MCP server: mcp-arcgis-pima
Tools
list_counties
Lists all counties with a verified parcel REST endpoint.
Parameter | Type | Required | Description |
| string | No | Two-letter abbreviation ( |
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
Fuzzy-matches a county by name or 5-digit FIPS code. Returns endpoint URLs, searchable field names, owner field, sample query, and license info.
Parameter | Type | Required | Description |
| string | Yes | County name ( |
Example prompt: "Find the parcel endpoint for Kane County Illinois"
get_parcel_endpoint
Returns the full ArcGIS REST URL, layer index, searchable fields, owner field, and a ready sample ?where=…&f=json query for a specific county.
Parameter | Type | Required | Description |
| string | Yes | Two-letter abbreviation or full name |
| string | Yes | County name ( |
Example prompt: "Give me the ArcGIS REST endpoint for Cook County Illinois"
build_owner_query
Constructs the exact ArcGIS REST query URL using the county's verified owner/taxpayer field. Uses UPPER(field) LIKE UPPER('%NAME%') — case-insensitive partial match.
Parameter | Type | Required | Description |
| string | Yes | Two-letter abbreviation or full name |
| string | Yes | County 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=25Example 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):
Calls
get_parcel_endpoint→ gets thegistech.countyofkane.orgURL and confirms the owner field isTaxNameCalls
build_owner_querywithowner_name=Blackstone→ returns a ready fetch URLOptionally 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.
License
MIT — © Leo Yong / UrbanKit Studio
Available Tools
4 toolsbuild_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
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter state abbreviation (e.g. 'IL') or full state name | |
| county | Yes | County name (e.g. 'Kane' or 'Kane County') | |
| owner_name | Yes | Owner/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
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | County 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
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter state abbreviation (e.g. 'IL') or full state name | |
| county | Yes | County 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
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Optional: 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. Dates show when Glama detected each change.
4 tool updates
v0.1.0- First observed
build_owner_query - First observed
find_county - First observed
get_parcel_endpoint - First observed
list_counties
TDQS
A4.1/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: building a query URL, fuzzy-matching counties, retrieving endpoint details, and listing counties. No functional overlap exists.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (build_owner_query, find_county, get_parcel_endpoint, list_counties), making the tool surface predictable.
Tool Count4/5
With only 4 tools, the set is minimal but well-scoped for the domain of parcel atlas lookups. No redundant tools exist, though a few more could be added for direct query execution.
Completeness4/5
The tools cover the core workflow: locate a county, get endpoint details, build a query, and list counties. A minor gap is the lack of a tool to directly execute the query, but the constructed URL enables external fetching.
Maintenance
ActivityNo data
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Property intelligence: 180M+ US parcels — lookup, search, owners, hazards, permits, deeds.
- mcpOAuthai.parceled
Real estate data for AI agents: US parcel boundaries (tiles), owners, sale history, permits, hail.
Official US-address public records: zoning, flood, parcel, permits, taxes. Free look, x402 paid.
Property Records MCP — address-level US property records (sales history,
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables searching and querying Pima County, Arizona open geospatial data (parcels, addresses, zoning, public works) through ArcGIS Feature Services.16MIT
- FlicenseNot gradedqualityCmaintenanceRead-only MCP server providing direct, credentialed access to parcel data via Regrid and county ArcGIS sources, with tools for querying by point, owner, size, and county.-
- FlicenseNot gradedqualityBmaintenanceProvides free property and parcel intelligence using official US government data APIs, county assessor records, and live listings, with tools for hazard risk checks, affordability calculations, and parcel ranking.-
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/LEOyrh/mcp-atlas'
If you have feedback or need assistance with the MCP directory API, please join our Discord server