Skip to main content
Glama
Sign In
gov-data-mcp

gov-data-mcp

by malonestar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

parcel-owner-lookup

Resolve a US street address to its parcel ID, owner name, mailing address and assessed value from official assessor rolls, with Census fallback where no roll is covered.

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. INPUTS: addresses is required, one full street address with city and state per entry. Coverage is a fixed list of county and state assessor rolls; every address still yields exactly one row, so read its lookup_status before treating a missing owner as an answer. maxResults caps addresses, one billed row each. 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

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "addresses": "<addresses>"
    },
    "name": "parcel-owner-lookup"
  }
}

Input 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.1/5.0
Behavior3/5

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

The description goes well beyond the annotations by explaining the metered billing model ($0.02 per result, discounted on paid Apify plans), that failed runs are not charged, and that runBudgetSeconds turns a slow roll into a lookup_status of source_unavailable with lookup_cut_by_deadline rather than hanging. It also reconciles readOnlyHint=false by clarifying the run is read-only against the government source but creates a metered run on the caller's account. It does not describe output row fields beyond lookup_status, though no output schema exists to cover that.

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?

It is front-loaded with the core purpose and coverage, then separates inputs from cost and side effects under explicit labels, which is easy to scan. The coverage enumeration is long and partly duplicates the addresses schema description, which is the main redundancy.

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 paid, open-world scraping tool with no output schema, the description covers coverage limits, the one-row-per-address contract, lookup_status semantics, fallback behavior, cost, and failure charging. It stops short of describing the returned owner/assessor fields in any detail, which is a modest gap given there is no output schema.

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 the baseline is 3, but the description adds real meaning: addresses must be full street addresses with city and state, maxResults caps addresses with one billed row per address, tying the parameter to cost. runBudgetSeconds is not discussed in the description text, leaving that parameter to the schema alone.

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 names a specific verb and resource: resolve a street address to a parcel ID, owner name, mailing address and assessed value from official assessor rolls. It also scopes the tool against siblings by stating the exact coverage list and noting that uncovered addresses fall back to Census geocoding, so an agent can tell this apart from the generic run-gov-data-tool.

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?

It gives clear usage context: one full street address with city and state per entry, the coverage list that determines whether a real owner record comes back, and an instruction to call describe-gov-data-tool (free) for a verified example input. It does not explicitly state when to prefer run-gov-data-tool or a different sibling instead, so it stops short of full when/when-not routing.

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