US parcel boundaries and assessor data: lookup by APN, point, radius or polygon.
Scored across 7 tools
Each lookup tool targets a distinct input modality (point, APN, polygon WKT, radius) and the credit costs and limits in the descriptions reinforce the boundaries. Minor overlap remains: find_parcels_in_polygon explicitly accepts a point geometry, which duplicates find_parcels_at_point at 3x the cost, and preview_area's bbox counting partially overlaps polygon lookups.
All names are snake_case verb_noun, with the four lookup tools forming a clean find_parcels_by_* / find_parcels_in_* family. The auxiliary tools (check_coverage, get_pricing, preview_area) use different but appropriate verbs and still follow the same pattern.
Seven tools is well-scoped for a parcel data API: four lookup methods, two free utility calls, and a pricing reference. Every tool maps to a distinct capability with no filler.
Core spatial and identifier lookups plus coverage, pricing and preview are all present, covering the main research workflows. The notable gap is the extract/download path referenced in get_pricing and preview_area — there is no tool to actually order or retrieve an extract, and no retrieve-by-parcel-id after a lookup returns candidates.
Free, no API key. Says whether a county is in the current data release, or lists every covered county in a state when no county is given. Parcel lookups in counties that are not covered cost no credits.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | USPS code, state name or 2-digit state FIPS, e.g. 'TX' | |
| county | No | Optional county name, 3-digit county code or 5-digit FIPS |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context the annotations cannot: it is free, requires no API key, and uncovered counties incur no credit charge — the cost/auth facts an agent needs before planning a sequence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, zero padding, with the cost/auth qualifier front-loaded and the mode switch stated before the credit caveat. Nothing restates the title or the annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter read-only tool with full schema coverage and rich annotations, the description covers both output modes, cost, and auth. The one gap is that with no output schema it never says what the response shape looks like (boolean vs list of counties), leaving the agent to infer the format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3. The description goes beyond it by defining the behavioral meaning of omitting county — the tool switches from a single-county boolean check to enumerating all covered counties in the state — which the schema's 'Optional county name' text does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource and covers both operating modes explicitly: it 'says whether a county is in the current data release' or 'lists every covered county in a state when no county is given'. The distinction from the find_parcels_* siblings is obvious from the resource named (coverage, not parcels).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Free, no API key' plus the credit note give practical context for deciding to call it, and the no-county case is described. However, no sibling is named as an alternative and there is no explicit instruction such as 'call this before find_parcels_by_apn to confirm the county is covered', so the when-to-use logic is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds the parcels that contain a latitude and longitude. Costs 1 credit per request, however many parcels come back. Up to 1,000 parcels per request. Needs an API key. Lookups in counties we do not cover and failed requests cost no credits. Returns parcel records with WKT boundaries in EPSG:4326, owner, address, assessed values, land use and zoning where the county publishes them.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude, decimal degrees | |
| lng | Yes | Longitude, decimal degrees | |
| limit | No | Parcels per request, 1 to 1,000 | |
| offset | No | Parcels to skip; each page is a new, charged request |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive, non-open-world), the description discloses billing (1 credit per request regardless of result count), the 1,000-parcel ceiling, API key requirement, non-charging failure/uncovered-county behavior, and the shape and CRS of the return payload. These are exactly the operational facts annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Six short sentences, front-loaded with what the tool does, then cost, then constraints, then return shape. Dense and readable; the only minor waste is restating the 1,000-parcel cap that the limit parameter already enforces.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only point lookup with four fully described parameters and no output schema, the description covers action, geometry, cost model, auth, coverage caveats, and returned fields. An agent has everything needed to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so lat/lng/limit/offset semantics are already fully documented in the schema, establishing a baseline of 3. The description adds a modest amount beyond that by tying the 1,000-parcel cap to billing behavior and noting results come back in EPSG:4326, but it does not explain offset paging beyond what the schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Finds the parcels that contain a latitude and longitude" gives a specific verb (finds), resource (parcels) and geometric scope (containment of a point). That scope cleanly separates it from the siblings find_parcels_in_polygon, find_parcels_in_radius and find_parcels_by_apn without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The costs-and-coverage sentences imply when the call is cheap or free (uncovered counties, failed requests) and hint that coverage should be verified first, which points at check_coverage/preview_area. But there is no explicit statement of when to choose this over find_parcels_in_radius or find_parcels_in_polygon, so routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds parcels by assessor parcel number (APN) in one county. Costs 1 credit per completed request, including no_match and ambiguous results. Up to 100 parcels per request. Validate each candidate before using it. Needs an API key. Lookups in counties we do not cover and failed requests cost no credits. Returns parcel records with WKT boundaries in EPSG:4326, owner, address, assessed values, land use and zoning where the county publishes them.
| Name | Required | Description | Default |
|---|---|---|---|
| apn | Yes | APN, with any leading zeros | |
| limit | No | Parcels per request, 1 to 100 | |
| state | No | USPS code, state name or 2-digit FIPS; needed with a county name | |
| county | Yes | County name, 5-digit FIPS or 3-digit county code | |
| offset | No | Parcels to skip; each page is a new, charged request | |
| match_mode | No | normalized ignores punctuation and case; exact needs the original identifier; contains (alpha) finds identifiers containing the input | normalized |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read, but the description adds substantial behavior beyond them: billing per completed request even for no_match/ambiguous results, no charge for uncovered counties or failed requests, an API-key requirement, and a validation warning. It also discloses the return payload shape (WKT boundaries in EPSG:4326, owner, address, assessed values, land use, zoning) with caveats about county publication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then cost, then constraints and return values in a logical order, with no filler sentences. Minor redundancy: 'Up to 100 parcels per request' restates the limit parameter's maximum that the schema already enforces.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully covers return contents, coordinate system, cost model, auth requirement, and result caveats for a six-parameter lookup tool. An agent has everything needed to call it and interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all six parameters are already documented, including the match_mode enum semantics and offset-as-new-charge. The description only echoes the 100-parcel cap and hints at ambiguity, adding little meaning beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Finds parcels by assessor parcel number (APN)') plus a scoping constraint ('in one county'), which cleanly separates it from the point/polygon/radius spatial siblings. An agent can pick this tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the credit-cost and coverage language ('counties we do not cover... cost no credits'), and 'Validate each candidate before using it' is actionable guidance. However, it never explicitly says when to prefer this over find_parcels_at_point or to call check_coverage first, so routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds every parcel that intersects a WKT geometry (polygon, multipolygon, line or point). Costs 3 credits per request, however many parcels come back. The geometry's bounding box can be up to 25 km². Up to 1,000 parcels per request. Needs an API key. Lookups in counties we do not cover and failed requests cost no credits. Returns parcel records with WKT boundaries in EPSG:4326, owner, address, assessed values, land use and zoning where the county publishes them.
| Name | Required | Description | Default |
|---|---|---|---|
| wkt | Yes | WKT in EPSG:4326 lon/lat order, e.g. POLYGON((-97.75 30.26, ...)) | |
| limit | No | Parcels per request, 1 to 1,000 | |
| offset | No | Parcels to skip; each page is a new, charged request |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish a safe read, but the description adds substantial behavior the annotations cannot: a flat 3-credit charge regardless of result size, no charge for uncovered counties or failures, and paging via offset being separately billed. Auth requirements and the meaning of the returned record fields are also disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Six short sentences, all front-loaded: purpose first, then cost, limits, auth, charge exceptions, and return payload. Nothing is repeated and no sentence could be dropped without losing information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on the burden of describing returns and does so concretely (WKT boundaries in EPSG:4326, owner, address, assessed values, land use, zoning, with a caveat that zoning is county-dependent). Combined with cost, rate, and auth facts, an agent has everything needed to call it correctly and interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description earns a step above it by adding the 25 km² bounding-box ceiling and the 1,000-parcel cap, neither of which is in the schema. It stops short of the 5 because the WKT coordinate order and format are already fully documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ("finds every parcel that intersects") and broadens the accepted input beyond the tool name by naming polygon, multipolygon, line and point WKT geometries. An agent can distinguish this from find_parcels_at_point or find_parcels_by_apn immediately, because the spatial-intersection semantics are stated outright.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It conveys clear usage context through hard constraints: a bounding-box ceiling of 25 km², a 1,000-parcel cap, and a required API key, which tells the agent when this tool is viable. It does not explicitly route to the sibling alternatives (point, radius, APN) or state when not to use this tool, which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds every parcel within a radius of a point, nearest first. Costs 3 credits per request, however many parcels come back. Radius up to 5,000 metres. Up to 1,000 parcels per request. Needs an API key. Lookups in counties we do not cover and failed requests cost no credits. Returns parcel records with WKT boundaries in EPSG:4326, owner, address, assessed values, land use and zoning where the county publishes them.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude, decimal degrees | |
| lng | Yes | Longitude, decimal degrees | |
| limit | No | Parcels per request, 1 to 1,000 | |
| offset | No | Parcels to skip; each page is a new, charged request | |
| radius_m | Yes | Radius in metres, up to 5,000 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already tell the agent this is a safe, read-only, idempotent lookup, but the description adds important operational behavior beyond them: 3 credits per request regardless of result count, no charge for uncovered counties or failed requests, API-key requirement, 5,000 m radius cap, 1,000 parcel cap, nearest-first ordering, and returned fields including WKT EPSG:4326. These details materially affect whether and how to call the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and ordering, then groups billing, limits, authentication, and return fields into a compact paragraph. It repeats the radius and parcel caps already present in the schema, which keeps it from a 5, but the repetition is operational rather than verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only spatial query with no output schema, the description supplies the missing context an agent needs: cost model, coverage-related free lookups, API-key requirement, result caps, ordering, and the shape of returned parcel records. Nothing essential for correct invocation appears absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents lat, lng, radius_m, limit, and offset with ranges and defaults. The description reinforces radius and limit caps and adds ordering and return-format context, but it does not explain parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb and resource — finds every parcel — plus the spatial scope (within a radius of a point) and ordering (nearest first). This clearly separates it from siblings such as find_parcels_at_point, find_parcels_in_polygon, and find_parcels_by_apn without requiring schema inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear the tool is for center-plus-radius searches, but it gives no explicit when-to-use guidance against alternatives like find_parcels_at_point or find_parcels_in_polygon, nor does it advise running check_coverage first. The radius and page-size limits imply suitable use cases but leave routing to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, no API key. Returns the monthly API plans (price, included credits, overage per credit, rate limit), the credit cost of each lookup type and the one-off extract downloads. Statewide and nationwide licences are quoted at https://getparceldata.com/pricing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely non-structured context — the call is free and requires no API key — and discloses the shape of the returned data (plan fields, per-lookup credit costs, extract download pricing), which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tightly packed with useful facts, and front-loaded with the highest-value qualifier ('Free, no API key'). Every clause earns its place by naming a returned data category or an out-of-scope case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no input parameters and no output schema, the description carries the burden of describing return values and it largely does so, listing plans, credit costs and extract downloads by field. It could be slightly firmer about the response structure or ordering, but nothing an agent needs in order to call it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly does not invent or discuss any inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Returns the monthly API plans...') and enumerates exactly what is returned: price, included credits, overage per credit, rate limit, plus per-lookup credit costs and one-off extract downloads. This is unmistakably distinct from the geo-lookup siblings like find_parcels_by_apn or check_coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes the context of use: it is free, needs no API key, and explicitly routes statewide/nationwide licence questions to an external pricing page rather than this tool. It does not spell out an explicit trigger (e.g. 'call this before estimating credit spend'), so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, no API key. Counts the parcels inside a bounding box, lists the counties it touches, and says whether the area fits the $49 extract of up to 5,000 parcels. Each side of the box can be up to 2 degrees. Limited to 30 requests per IP address per minute.
| Name | Required | Description | Default |
|---|---|---|---|
| east | Yes | Eastern longitude, EPSG:4326 | |
| west | Yes | Western longitude, EPSG:4326 | |
| north | Yes | Northern latitude, EPSG:4326 | |
| south | Yes | Southern latitude, EPSG:4326 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, non-destructive and openWorld=false, and the description goes further with a 30 requests/IP/minute rate limit, the 2-degree-per-side box cap (a constraint the schema does not express), and a no-API-key access note. It stops short of saying whether the returned count is exact or an estimate, which matters for a tool named 'preview'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the access/cost fact, then capability, then hard limits. No filler and nothing repeated from the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still names all three return components, and it covers cost, access, rate limits and box size for a simple four-parameter read. Minor gaps remain on edge cases such as antimeridian-crossing boxes and count accuracy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each bound is documented with EPSG:4326 semantics, so the schema carries most of the load and the baseline is 3. The description adds real meaning by framing the four numbers as a bounding box and constraining each side to at most 2 degrees, which the schema's per-value min/max does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Counts the parcels inside a bounding box') plus its three outputs: parcel count, touched counties, and a $49-extract fit verdict. It is clearly distinguishable from siblings like find_parcels_in_polygon or find_parcels_in_radius because the scope is explicitly a bounding box.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The '$49 extract of up to 5,000 parcels' fit check and 'Free, no API key' imply this is the cheap pre-quote step before calling find_parcels_* or get_pricing, but the description never names those alternatives or states exclusions explicitly. Usage is inferable rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_coveragefind_parcels_at_pointfind_parcels_by_apnfind_parcels_in_polygonfind_parcels_in_radiusget_pricingpreview_areaUS parcel records plus utilities, power, grid, environmental and logistics data by address or point.
US parcels, owners, sales, zoning rules, building permits and zoning cases.
US parcel, zoning, ordinance and permit data, with a Python sandbox to query and map it
Property intelligence: 180M+ US parcels — lookup, search, owners, hazards, permits, deeds.
Add one secure layer between your agents and this server.
