zillow-leads-property-data

Overview Schema Source Related Servers Score Discussions Admin

germane_binoculars--zillow-leads-property-data

Fetch Zillow property leads with agent contact info, price/tax history, foreclosure flags, and schools via instant catalog or live metro searches.

Instructions

Calls the Actor "germane_binoculars/zillow-leads-property-data" and retrieves its output results: Zillow listings enriched with agent/broker contact info, price/tax history, foreclosure flags, and schools. Catalog mode is an instant paid sample that usually returns rows in a single call. Every other mode dispatches a live-collection order measured in minutes to hours; such calls return a runId plus status immediately — poll via get-actor-run, then fetch rows with get-dataset-items. If a previous call was lost to a client timeout, DO NOT re-submit (you would pay twice): recover the existing runId with get-actor-run-list.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	No	Pick ONE mode; only that mode's fields apply. Catalog: instant snapshot from the pre-seeded catalog pool, returns in seconds, always fully enriched; metro (below) optionally scopes it to one metro, otherwise the whole pool counts. Custom search: your own lat/lng bounding box or a named metro, live-collected, the only mode with a cheaper 'listings' depth option. Recent activity: Zillow's sitemap feed of newest/changed listings nationwide, no bounds, always fully enriched.	catalog
`depth`	No	Only read when mode = custom_search; ignored (always enriched) for catalog and recent_activity. 'listings': bare address/price/beds/baths/status, cheaper, faster (see README 'Bare listing schema'). 'enriched': full agent contact, price/tax history, foreclosure, schools, resoFacts (see README 'Enriched schema'), costs more per row.	enriched
`metro`	No	Pick a named metro instead of typing lat/lng bounds by hand. Covers the metro's whole urbanized area, not just city limits, so results genuinely include real suburbs along with the named city (e.g. Phoenix also returns Scottsdale/Tempe/Glendale); see the README. For custom_search: required if bounds is not set; bounds always wins when both are present. For catalog: optional, scopes the instant snapshot to this metro instead of the whole cached pool; leave unset to use everything cached. For recent_activity: ignored.	Phoenix
`bounds`	No	custom_search only (ignored for catalog/recent_activity). A lat/lng box, for a precise custom area metro doesn't cover. North/south are latitude, east/west are longitude, and north/east must each be numerically LARGER than south/west respectively (it's a box, not two arbitrary points; a swapped box is rejected). Takes priority over metro if both are set. Leave empty to use metro instead.
`source`	No	Which Zillow sitemap feed to pull recent activity from. Always fully enriched (no bare/listings option exists for this mode; the sitemap feed itself carries nothing beyond a listing URL, so there's no cheaper variant to offer).	agent
`waitSecs`	No	Max seconds (0-45) to block on this single call waiting for terminal run status. Unset: catalog smoke tests block up to 30s and often return rows in one call; every other mode is fire-and-forget (returns runId immediately) because collection takes minutes. Poll with get-actor-run, then fetch rows with get-dataset-items.
`dedupZpids`	No	Optional. zpids you've already received from a prior run, e.g. [43814015, 43828670]; never re-shipped.
`dedupMlsIds`	No	Optional. MLS IDs you've already received from a prior run, e.g. ["A12046823"]; covers re-listings, which get a new zpid but keep the same MLS ID, so zpid-only dedup would miss them.
`minEnriched`	No	Optional, defaults to 500 (the recommended floor). Only meaningful when rows are actually being enriched: custom_search + depth=enriched, catalog, or recent_activity. Ignored (forced to 0 internally) for custom_search + depth=listings, since a listings-depth order never enriches anything by design. Must be <= whatever minListings you set; asking for more enriched rows than total rows is a nonsensical order and won't be satisfiable.
`minListings`	No	Optional, defaults to 1000 (the recommended floor). The floor for how many rows (bare or enriched, whichever depth you asked for) this run must return before considering itself done. Applies to every mode. Set lower (e.g. 10-50) only for a quick test run before committing to a full one.
`timeoutSecs`	No	Optional, defaults to 7200 (2 hours), minimum 300 (5 minutes). Max wait for the minimums to be satisfied before returning a partial dataset. A cache-satisfiable order (catalog, or already-covered ground) finishes in seconds regardless; this only matters when live collection is needed. The 5-min floor exists because live collection needs that long for PX-safe warmup pacing.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.0.9Aug 23, 2026

changedInput schema / properties / waitSecs / description

Previous value: -"Max seconds (0-45, default 30) to block on this single call waiting for terminal run status. Long-running orders return a status plus nextStep instead."New value: +"Max seconds (0-45) to block on this single call waiting for terminal run status. Unset: catalog smoke tests block up to 30s and often return rows in one call; every other mode is fire-and-forget (returns runId immediately) because collection takes minutes. Poll with get-actor-run, then fetch rows with get-dataset-items."

Changed5 schema fields changedv1.0.5Aug 22, 2026

addedInput schema / properties / bounds / additionalProperties
```
Added value: +false
```

addedInput schema / properties / bounds / properties

Added value: +{
+  "east": {
+    "description": "Right edge longitude; must be numerically larger than west.",
+    "title": "East",
+    "type": "number"
+  },
+  "north": {
+    "description": "Top edge latitude; must be numerically larger than south.",
+    "title": "North",
+    "type": "number"
+  },
+  "south": {
+    "description": "Bottom edge latitude.",
+    "title": "South",
+    "type": "number"
+  },
+  "west": {
+    "description": "Left edge longitude.",
+    "title": "West",
+    "type": "number"
+  }
+}

addedInput schema / properties / bounds / required

Added value: +[
+  "north",
+  "east",
+  "south",
+  "west"
+]

removedInput schema / properties / dedupMlsIds / items / title
```
Removed value: -"MLS ID"
```
removedInput schema / properties / dedupZpids / items / title
```
Removed value: -"zpid"
```

Changed2 schema fields changedv1.0.4Aug 22, 2026
- addedInput schema / properties / dedupMlsIds / items
```
Added value: +{
+  "title": "MLS ID",
+  "type": "string"
+}
```
- addedInput schema / properties / dedupZpids / items
```
Added value: +{
+  "title": "zpid",
+  "type": "integer"
+}
```
Addedv0.1.2Aug 22, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations available, the description carries the full behavioral burden, and it does so thoroughly: it discloses paid catalog behavior, minute-to-hour live collection, immediate runId;+status return, polling requirements, and the financial risk of duplicate submission. This goes well beyond the input schema and explains the tool's real runtime behavior.

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

Conciseness5/5

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

The description is dense but every sentence earns its place, front-loading the core action (actor call plus output) before covering mode timing, polling workflow, and the duplicate-payment warning. It manages to capture a complex tool's essential behavior without padding or redundancy.

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?

For an 11-parameter, multi-mode tool with no output schema and no annotations, the definition is remarkably complete when combined with the schema: it explains mode selection, timing expectations, minimums, dedup, bounds, and post-run follow-up. There is no obvious critical context an agent would need to invoke this tool correctly that is left unaddressed.

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 itself already documents every parameter and mode interaction; the scoring baseline is therefore 3. The description does add high-level context around modes and run lifecycle, but it does not meaningfully enrich individual parameter semantics beyond 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?

The description opens with a specific verb plus resource: it calls the Actor "germane_binoculars/zillow-leads-property-data" and retrieves its output results. It names concrete data content (Zillow listings, agent/broker contacts, price/tax history, foreclosure flags, schools), which makes the tool's purpose unmistakable and distinct from the sibling retrieval tools.

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 gives explicit mode-based usage guidance: catalog is instant, other modes launch live collection, and follow-up should use get-actor-run and get-dataset-items. It also includes a strong exclusion/alternative rule: do not resubmit after a client timeout; recover the runId with get-actor-run-list instead.

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

Install Server

germane_binoculars--zillow-leads-property-data

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools