Property Owner Records MCP Server

Look up property owners of record from county tax rolls

lookup_property_owner_records

Read-onlyIdempotent

Find property owners of record and tax roll details using an address, parcel ID, owner name, or ZIP code across six US states.

Instructions

Give US street addresses, or a state (NC, NY, FL, CO, AR, WI) with parcel IDs, owner names, or ZIP codes. Returns one row per parcel from public county tax rolls with the owner of record, the tax roll mailing address, property address, assessed and market values, land use, and last sale where published. No phone numbers or emails. Misses are free. Pay per event on Apify: 0.02 USD per parcel row.

Input Schema

Name	Required	Description
`state`	No	Two letter state for parcel_ids, owner_names, and zip_codes: NC, NY, FL, CO, AR, or WI.
`county`	No	Optional county name, such as Wake or St. Lawrence, to narrow parcel_ids, owner_names, and zip_codes. Does not apply to addresses.
`addresses`	No	Full US street addresses with city and state, one per entry, such as 1 E Edenton St, Raleigh, NC 27601. The US Census geocoder places each one and the actor returns the parcel at that point. The state comes from the address, so the state field is not needed. An address it cannot place, or one outside the covered states, is a free row.
`zip_codes`	No	5 digit property ZIP codes. Returns every parcel in the ZIP up to max_results_per_lookup. Needs state.
`parcel_ids`	No	Parcel numbers as the county writes them. Needs state. Add county, because the same number can repeat in two counties.
`owner_match`	No	starts_with (default): the owner name starts with your text. contains: the text appears anywhere in the name; slower, so add a county.
`owner_names`	No	Owner names as the roll writes them, usually last name first for a person (SMITH JOHN) and the full name for a company (CITY OF RALEIGH). Needs state. Matches names that start with the text unless owner_match is contains.
`max_charge_usd`	No	Optional. The run stops before a charge that would pass this amount. Summary rows are always returned.
`max_results_per_lookup`	No	Parcel rows per address, parcel ID, owner name, or ZIP, from 1 to 5000. Default 25.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 9, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: per-row pricing on Apify (0.02 USD per parcel row), free misses, the max_charge_usd cost ceiling, and explicit scope exclusions ('No phone numbers or emails', 'where published').

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?

Four short sentences, front-loaded with the accepted inputs and followed by return contents, exclusions, and cost. Dense and largely waste-free, though the telegraphic phrasing ('Misses are free') and pricing sentence read as appended rather than integrated.

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?

With no output schema, the description compensates by enumerating returned fields (owner of record, mailing address, property address, assessed and market values, land use, last sale). Cost model, coverage limits, and free-miss behavior are all disclosed; only rate limiting or runtime expectations are absent, which is minor.

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?

Schema description coverage is 100%, so the schema already documents every parameter, and the description largely restates those combinations rather than adding new meaning. The one increment is the upfront framing of which input types pair with a state, which helps an agent pick a mode before reading the schema.

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?

States the resource (property owners of record from county tax rolls), the accepted input types (US street addresses, or a state plus parcel IDs/owner names/ZIPs), and the exact output grain ('one row per parcel'). The covered states are enumerated, so an agent knows immediately whether the tool applies to a given request.

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?

Explains the two input modes and what each requires (state+county for parcel/owner/ZIP, self-contained for addresses), and sets expectations that misses are free. It does not spell out when to prefer one mode over the other or when not to use the tool, though with no sibling tools there is no alternative to route against.

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

Deploy Server

Other Tools

lookup_property_owner_recordsA