Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Property Owner Records MCP Server Who owns 222 W Hargett St, Raleigh, NC 27601?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for the Mamba Labs Property Owner Records actor on Apify. Addresses or parcels in, owners of record from county tax rolls out.
Related MCP server: Property Intelligence MCP Server
Give US street addresses, or a state with parcel IDs, owner names, or ZIP codes. The actor reads six public statewide parcel layers built from county assessor rolls (NC, NY in 38 counties, FL, CO, AR, WI) and returns one row per parcel with the owner of record, the mailing address on the roll, the property address, assessed and market values, land use, and last sale where the county publishes it. It returns no phone numbers or emails and uses no data broker.
All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:
{
"mcpServers": {
"mamba-property-owner-records": {
"command": "npx",
"args": [
"-y",
"@mambalabsdev/mcp-property-owner-records"
],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Restart the client. The lookup_property_owner_records tool appears.
Node.js 18 or newer.
An Apify API token from console.apify.com/account/integrations, set as APIFY_TOKEN. The server lists its tool without a token; a call needs one.
"Who owns 222 W Hargett St, Raleigh, NC 27601?"
"List the parcels the City of Raleigh owns in Wake County, North Carolina."
"Export the owners of record for every parcel in ZIP 27601."
lookup_property_owner_records. One tool. Example arguments:
{
"addresses": [
"1 E Edenton St, Raleigh, NC 27601"
],
"owner_names": [
"CITY OF RALEIGH"
],
"state": "NC",
"county": "Wake",
"max_results_per_lookup": 5
}Every buyer facing input of the actor. Omitted inputs take the actor's own defaults.
Input | Type | Required | Description |
| array | 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. |
| array | no | Parcel numbers as the county writes them. Needs state. Add county, because the same number can repeat in two counties. |
| array | 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. |
| array | no | 5 digit property ZIP codes. Returns every parcel in the ZIP up to max_results_per_lookup. Needs state. |
| string | no | Two letter state for parcel_ids, owner_names, and zip_codes: NC, NY, FL, CO, AR, or WI. |
| string | no | Optional county name, such as Wake or St. Lawrence, to narrow parcel_ids, owner_names, and zip_codes. Does not apply to addresses. |
| string | no | starts_with (default): the owner name starts with your text. contains: the text appears anywhere in the name; slower, so add a county. |
| number | no | Parcel rows per address, parcel ID, owner name, or ZIP, from 1 to 5000. Default 25. |
| string | no | Optional. The run stops before a charge that would pass this amount. Summary rows are always returned. |
Pay per event on Apify, billed to your Apify account. Prices in USD.
Event | Free plan | Bronze | Silver | Gold |
| $0.02 | $0.019 | $0.018 | $0.017 |
| $0.009 | $0.009 | $0.009 | $0.009 |
Lookup summaries, misses, refused requests, and refused input are free. Mamba Labs pays the platform costs of the run. Mamba Labs pays the platform costs of the run, Apify proxy traffic included.
apify.com/mambalabs/property-owner-records
MIT. See LICENSE.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0lookup_property_owner_recordsScored across 1 tool
With only one tool in the set, there is no possibility of confusion or misselection between tools. The single tool's purpose (property owner record lookup) is clearly and unambiguously stated.
The sole tool follows a clear verb_noun convention (lookup_property_owner_records) in snake_case. There is nothing to be inconsistent with, so the naming is trivially predictable.
A single tool is on the thin side even for a focused lookup service, which typically benefits from at least a search plus a detail/export variant. The count is borderline rather than clearly wrong for a narrow domain.
The tool appears to cover the core lookup and returns rich row-level data, but there are no companion operations (e.g. bulk export, schema/field discovery, or a coverage check for supported states) that agents would often need. The surface is functional but minimally so for a data-retrieval service.
US parcel boundaries and assessor data: lookup by APN, point, radius or polygon.
Property intelligence: 180M+ US parcels — lookup, search, owners, hazards, permits, deeds.
Find US property owners, including LLCs, plus owner phones and emails. Needs a DealMachine account.
Property Records MCP — address-level US property records (sales history, assessed value, owner…
