Skip to main content
Glama
malonestar

gov-data-mcp

by malonestar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

parcel-owner-lookup

Resolve US street addresses to parcel IDs, owner names, mailing addresses, and assessed values from official assessor rolls.

Instructions

Parcel Owner Lookup — Address to Owner & Assessor Record. Address to parcel ID, owner name, mailing address & assessed value from official assessor rolls: Chicago, Philadelphia, NYC + NC, NY State, WI, CO, MN, AR, MA, CT, VT statewide, Phoenix, Houston, Cleveland, Nashville & DC. Census fallback elsewhere. $0.02/lookup. Reads live from the official government source. Call describe-gov-data-tool (free) for a verified example input. COST AND SIDE EFFECTS: read-only with respect to the government source — it never writes to any external system — but each call starts a metered run on YOUR Apify account, billed $0.02 per Result ($20 per 1,000). Lower on paid Apify plans, down to $6.00 per 1,000. Nothing is charged when a run fails. Store page: https://apify.com/malonestar/parcel-owner-lookup

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressesYesUS street addresses to resolve to a parcel + owner record, one per line (e.g. '1060 W Addison St, Chicago, IL'). Matched against the Cook County IL (Chicago), Philadelphia PA and New York City rolls, plus (v1.1) statewide rolls for North Carolina, New York State, Wisconsin, Colorado, Minnesota (opt-in counties), Arkansas, Massachusetts, Connecticut and Vermont and county rolls for Maricopa AZ (Phoenix), Harris TX (Houston), Cuyahoga OH (Cleveland), Nashville TN and Washington DC - routed by the Census-geocoded point's county. Addresses elsewhere fall back to Census geocoding (lat/lon only). Every input address yields exactly one output row; see lookup_status on each row. Example: ["1060 W Addison St, Chicago, IL","1234 Market St, Philadelphia, PA","350 5th Ave, New York, NY"].
maxResultsNoMaximum number of addresses to process (one output row per address). Extra addresses beyond this cap are skipped. Example: 10. Applied by default if omitted: 100.
runBudgetSecondsNoOptional wall-clock budget for the whole run. A parcel roll that is slow to answer is cut when the budget runs out: that address comes back lookup_status "source_unavailable" (or keeps the answer the house-number query already gave) with lookup_cut_by_deadline: true, instead of the run hanging. Leave empty for no budget. Example: 240.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.6
    • addedInput schema / properties / runBudgetSeconds
      Added value: +{
+  "description": "Optional wall-clock budget for the whole run. A parcel roll that is slow to answer is cut when the budget runs out: that address comes back lookup_status \"source_unavailable\" (or keeps the answer the house-number query already gave) with lookup_cut_by_deadline: true, instead of the run hanging. Leave empty for no budget. Example: 240.",
+  "maximum": 3600,
+  "minimum": 30,
+  "type": "integer"
+}
  2. Changed1 schema field changedv1.2.0
    • changedInput schema / properties / addresses / description
      Previous value: -"US street addresses to resolve to a parcel + owner record, one per line (e.g. '1060 W Addison St, Chicago, IL'). v1 matches against the Cook County IL (Chicago), Philadelphia PA, and New York City assessment rolls; addresses outside those areas fall back to Census geocoding (lat/lon only). Every input address always yields exactly one output row — unmatched addresses come back with match_confidence 'none'. Example: [\"1060 W Addison St, Chicago, IL\",\"1234 Market St, Philadelphia, PA\",\"350 5th Ave, New York, NY\"]."New value: +"US street addresses to resolve to a parcel + owner record, one per line (e.g. '1060 W Addison St, Chicago, IL'). Matched against the Cook County IL (Chicago), Philadelphia PA and New York City rolls, plus (v1.1) statewide rolls for North Carolina, New York State, Wisconsin, Colorado, Minnesota (opt-in counties), Arkansas, Massachusetts, Connecticut and Vermont and county rolls for Maricopa AZ (Phoenix), Harris TX (Houston), Cuyahoga OH (Cleveland), Nashville TN and Washington DC - routed by the Census-geocoded point's county. Addresses elsewhere fall back to Census geocoding (lat/lon only). Every input address yields exactly one output row; see lookup_status on each row. Example: [\"1060 W Addison St, Chicago, IL\",\"1234 Market St, Philadelphia, PA\",\"350 5th Ave, New York, NY\"]."
  3. First observedv1.0.2

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses per-Result metering ($0.02/lookup, $20 per 1,000, as low as $6/1,000 on paid plans), that nothing is charged on failure, that each call starts a run on the caller's Apify account, and that one output row is guaranteed per input address via lookup_status. It also explains deadline-cut behavior (lookup_cut_by_deadline, 'source_unavailable'), reconciling the readOnlyHint=false annotation by clarifying it is read-only toward the government source but creates a billed run.

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?

Front-loaded with the core purpose before coverage, pricing, and side effects, and the 'COST AND SIDE EFFECTS' block is clearly signposted. It is somewhat long and includes a store-page URL and pricing repetitions that could be trimmed, but nearly every sentence carries operational 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?

For a metered, no-output-schema tool the description covers inputs, routing/fallback logic, billing, failure semantics, and the derived output fields (lookup_status, lookup_cut_by_deadline). An agent has enough to invoke correctly; only the concrete result record shape is left unspecified, which is minor given the fields it names.

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 all three parameters (addresses, maxResults, runBudgetSeconds) are already fully documented in the schema, including defaults and edge behavior. The description adds little parameter-level detail beyond what the schema states, so baseline 3 applies.

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 a specific verb and resource ('Address to parcel ID, owner name, mailing address & assessed value from official assessor rolls'), naming exactly what is produced. It enumerates the jurisdictions served and the Census fallback, so an agent knows the precise scope without opening the schema. The sibling tool describe-gov-data-tool is also named, distinguishing this from generic lookups.

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?

Gives clear context: address-to-owner resolution with a Census geocoding fallback for uncovered areas, plus an explicit pointer to call describe-gov-data-tool for a verified example input before invoking. What is missing is explicit when-not-to-use guidance versus the other gov-data siblings (e.g., run-gov-data-tool), which is left implicit.

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