Skip to main content
Glama

Parcel record for a point, address or APN

parcel_enrich
Read-onlyIdempotent

Get the public parcel (property) record for one US parcel, located by exactly one of: lat+lng, street address (matched to the parcel's situs address nearby), parcel_id from an earlier result, or apn+state. Sibling tools: parcel_search finds many parcels by criteria and returns lighter records; start_run (kind=enrich) enriches up to 1000 parcels; parcel_coverage lists covered states and their columns. Output: parcel with owner of record and mailing address (null with privacy.reason where the source or state law withholds them), situs address, land use, zoning where published, assessed/land/improvement values, last sale, year built, legal description, acres, square feet, perimeter, centroid, bounding box and shape metrics; the GeoJSON boundary with include_geometry; point_fields computed at the centroid when fields or preset are given. Columns vary by state. Cost: 5 lookups per matched parcel plus 1 per started block of 50 point fields that return data; nothing when no parcel matches. Errors: invalid_locator (none or several locators), parcel_not_found (free; also outside covered states), fields_unknown, preset_unknown. Plan limits return rate_limited (with retry_after_s), daily_cap_reached or quota_exhausted.

Input Schema

NameRequiredDescriptionDefault
apnNoThe publisher's parcel number (APN/PIN); spaces and punctuation are ignored. Requires state.
latNoWGS84 latitude in decimal degrees (e.g. 30.2672), paired with lng. One of four locators: lat+lng, address, parcel_id or apn+state.
lngNoWGS84 longitude in decimal degrees (e.g. -97.7431, negative in the US), paired with lat.
stateNoTwo-letter state code (e.g. 'TX'), required with apn and unused otherwise.
countyNoOptional county, 5-digit FIPS or name, to disambiguate an apn that repeats across counties.
fieldsNoOptional point-field names (from search_fields) computed at the parcel centroid and returned in point_fields. Parcel columns are always returned and need not be listed.
presetNoOptional preset of point fields (from list_presets) computed at the parcel centroid, combined with fields.
addressNoUS street address with city and state (e.g. '350 5th Ave, New York, NY'), geocoded by the US Census geocoder along the street. An alternative to lat+lng; giving both is an invalid_locator error.
parcel_idNoIsopleth parcel id from an earlier parcel_search or parcel_enrich result (e.g. 'tx-1234567'). Ids change when a state's data is refreshed.
max_wait_sNoSeconds to wait for slow live sources before returning those fields as failed; default 10 s, capped at 15 s on Free and 30 s on paid plans. Optional.
include_geometryNotrue adds the parcel boundary as GeoJSON (can be large). Default false; acreage and shape metrics are returned either way.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior. The description adds substantial context beyond annotations: cost per matched parcel and per point-field block, free no-match behavior, privacy withholding of owner/mailing fields, state-dependent columns, and plan-related errors including rate_limited with retry_after_s.

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

Conciseness4/5

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

The description is dense and long, but it is front-loaded with purpose and locator rules before moving to sibling differentiation, outputs, cost, and errors. Most sentences carry operational value for a complex lookup tool, though the output and error inventory could be tightened.

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

Completeness5/5

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

There is no output schema, so the description carries the return-value burden and does so thoroughly: owner/mailing address privacy behavior, situs address, land use, zoning, values, sale, built year, legal description, geometry, and point_fields. It also documents state variation and error conditions, making the definition complete for safe and correct invocation.

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%, so parameter definitions are already strong. The description still adds useful semantic constraints not fully captured in individual schema fields, especially the exactly-one-locator rule, the free no-match behavior, point-field cost, and centroid computation for fields/preset.

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 states a specific verb and resource: get the public parcel record for one US parcel. It clearly defines the accepted locator forms and distinguishes parcel_enrich from parcel_search, start_run(kind=enrich), and parcel_coverage, so an agent can identify the correct tool without opening other schemas.

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

Usage Guidelines5/5

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

The description explicitly says the parcel must be located by exactly one of lat+lng, street address, parcel_id, or apn+state, and names sibling alternatives with their distinct roles. It also covers error cases such as invalid_locator when multiple locators are supplied, which directly guides correct invocation.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources