# Reported issues for zillow-mcp

Pod holds 23 of 41 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [zillow-mcp](/mcp/zillow-mcp).

## Most discussed

### real-world #26: raise zillow_compare_properties cap from 8 → 25, or add bulk endpoint

## Motivation (from real-world report section 26)

> Zillow: `zillow_compare_properties` cap is 8 like onehome. Raise to 25, or add bulk endpoint, same pattern as onehome P1 #7. Same for Compass and Redfin compare endpoints if they exist.

## Two options (pick at least one, preferably both)

**A. Raise `zillow_compare_properties` cap from 8 -> 25.** Lower-effort. Existing tool surface; concurrent fan-out same shape as today. Cuts a 53-listing workflow from 7 round trips to 3.

**B. Add `zillow_b

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/60) · 2026-05-27 · closed · 1 comment

### real-world #23: tool description honesty sweep (44-result cap, etc.)

## Motivation (from real-world report section 23)

> Many tool descriptions oversell or omit critical caveats. Real examples from today:
>
> - `zillow_search_properties` doesn't mention the 44-result cap
> - `redfin_search_properties` doesn't mention rural-ZIP failure mode
> - `compass_get_by_address` doesn't mention the silent-wrong-match bug
> - `redfin_get_climate_risk` mentions empty-on-missing but doesn't enumerate WHY data might be missing
> - No MCP documents that addresses across systems

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/59) · 2026-05-27 · closed · 1 comment

### real-world #13: additional derived fields — last_sold_date, last_sold_price, zest_vs_list_pct

## Motivation (from real-world report section 13)

The report calls for a set of derived fields on every property record:

> - `days_on_market` (int) — mirror to others
> - `price_drop_amount` and `price_drop_percent`
> - `price_per_sqft` — standardize the field name
> - `last_sold_date`, `last_sold_price` — extracted from the price history, not requiring a separate call
> - `zest_vs_list_pct` (zillow only) — `(list_price - zestimate) / zestimate` rounded to one decimal

The `days_on_market` + `

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/57) · 2026-05-27 · closed · 1 comment

### real-world #12: bundle history into zillow_get_property via include_price_history + include_tax_history flags

## Motivation (from real-world report section 12)

> Today I needed all three for most workflows; 3 separate tool calls × 53 properties = 159 unnecessary round trips. Add `include_price_history: bool` and `include_tax_history: bool` flags to `get_property` on every MCP that has separate history tools (zillow, redfin, homes-com — compass already returns most of this inline).

## Change

Add to `zillow_get_property` input:

- `include_price_history: boolean` (default `false`)
- `include_tax_histor

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/56) · 2026-05-27 · closed · 1 comment

### real-world #4: add bulk zillow_resolve_addresses(addresses[])

## Motivation (from real-world report section 4)

> Today I had 60 addresses across two sessions; getting URLs for all of them took ~6 search calls + ~15 individual resolves + manual matching. A single batch call that takes an array and returns `[{address, resolved, url, id, confidence}]` collapses this to one round trip.

The report calls for this across all five real-estate MCPs (onehome, zillow, redfin, compass, homes-com). This issue tracks the Zillow side.

## API

```
zillow_resolve_addres

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/53) · 2026-05-27 · closed · 1 comment

### real-world #3: zillow_get_by_address — fall through to search when direct resolve fails

## Problem (from real-world report section 3)

> zillow_get_by_address fails for properties that demonstrably exist on Zillow. "126 Sleeping Bear Ln, Lake Lure, NC 28746" returned `resolved: false`, but `zillow_search_properties("Lake Lure, NC", price_min=620000, price_max=640000)` returns that exact zpid as the first result.

Callers end up manually implementing the search-then-string-match workaround for every failed resolve. Bake it in.

## Fix

When direct `zillow_get_by_address` fails (incl

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/52) · 2026-05-27 · closed · 1 comment

### surface address_alternates[] when upstream MLS data has them

## Motivation

A real session has an ongoing "109 vs 169 Overlook Point Ln" discrepancy between Compass and Canopy MLS. Zillow generally agrees with the MLS, but the same listing can carry alternate address strings (different MLS feeds, prior addresses, parcel variants). Better data plumbing might flag the discrepancy sooner.

## Fix

If the upstream Zillow payload exposes alternate address strings, surface them as `address_alternates: string[]` on the formatted record. Omit the field when absen

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/50) · 2026-05-27 · closed · 1 comment

### add portal_url_hyperlink (Google-Sheets formula) to every property record

## Motivation

Today's real-world session built 53 of these by string concat. Lift the URL-pattern knowledge server-side.

## Schema

Add `portal_url_hyperlink: string` to every property record:

```
portal_url_hyperlink: '=HYPERLINK("https://www.zillow.com/homedetails/<slug>/<zpid>_zpid/","Zillow")'
```

Mirrors the per-row `url` field but in Sheets-paste-ready form. Use the canonical Zillow homedetails URL pattern (with the slug + `_zpid` suffix) so the link resolves cleanly without redirect.

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/49) · 2026-05-27 · closed · 1 comment

## Most recent

### Auto-review follow-ups for PR #171: feat(skill): add zillow fpx access skill

<!-- auto-review-followup:PR-171 -->

Tracking auto-review follow-ups for #171 (verdict: **fail**).

### 🔴 Important
- [x] references/pages.md line 120: Zestimate-history jq recipe `.homeValueChartData[] | select(.name=="This home") // .homeValueChartData[0] | .points` is broken by jq pipe/`//` precedence — returns null instead of falling back to the first chart when no "This home" entry exists — fixed to `(first(.homeValueChartData[] | select(.name=="This home")) // .homeValueChartData[0]) | .p

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/172) · 2026-07-13 · closed · external user · 0 comments

### Shirk the static persisted-query hash: make the GraphQL property fetch inline-first, self-adapting, and degrade safely

## Problem

`src/tools/graphql-property.ts` (from #99/#102) fetches property detail via a persisted-query GET:

```
GET /graphql/?extensions={persistedQuery:{version:1,sha256Hash:<HASH>}}&variables=...
```

keyed on a static `PROPERTY_DETAIL_SHA256_HASH` constant (env override `ZILLOW_PROPERTY_QUERY_HASH`). The brittleness: **Zillow rotates the hash per-deploy**, the pinned constant goes stale, the call returns `PersistedQueryNotFound`, and we silently drop to the SSR `/homedetails/` scrape — wh

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/103) · 2026-05-29 · closed · 0 comments

### Resolver typeahead: use the canonical zg-graph GetAutocompleteResults endpoint

From a usage session (2026-05-29). Captured for a **follow-up** to the in-flight transport/resolver PR (do this after that lands to avoid conflicts). Relates to the P1-2 typeahead-under-recall finding.

The site's own address autocomplete/typeahead uses a GraphQL endpoint that returns clean suggestions and — importantly — sends the **query inline** (not a persisted-query hash), so it has **no hash-rotation fragility** (unlike the property-detail persistedQuery endpoint). The bridge supplies cook

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/101) · 2026-05-29 · closed · 0 comments

### P1: address resolver — promote search-fallback to a first-class rung on typeahead timeout/empty

## Usage report
The shared address resolver (`src/tools/resolver.ts`, used by `zillow_get_by_address` + `zillow_resolve_addresses`) runs a 4-rung ladder: direct → suffix-expansion → locality-remap → search-fallback. The direct rung (rung 1, the typeahead-equivalent `/homes/<slug>_rb/` resolve) currently **propagates a transport timeout** — if rung 1 *times out* (rather than cleanly missing), the whole ladder aborts and the search-fallback rung is never reached.

## Fix
When the typeahead/direct 

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/100) · 2026-05-29 · closed · 0 comments

### P0: move primary property fetch to the persistedQuery GraphQL endpoint (SSR scrape trips PerimeterX at scale)

## Usage report
The current property-detail path scrapes the SSR `/homedetails/<zpid>_zpid/` page and parses `__NEXT_DATA__`. At scale this **trips PerimeterX** (~20 ids ok, ~59 trips the bot-wall), even though the site's own GraphQL API still works for the same listings.

## Fix — adopt Zillow's persistedQuery GraphQL API as the primary fetch (through the bridge, ambient cookies)
- **Endpoint:** `https://www.zillow.com/graphql/?extensions=<urlencoded {"persistedQuery":{"version":1,"sha256Hash":

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/99) · 2026-05-29 · closed · 0 comments

### P0: bulk_get wedges the whole MCP on a slow/hanging row — no overall deadline, no partial results

## Usage report
A 59-zpid `zillow_bulk_get` call hung for the **full MCP client timeout** and then **poisoned the connection** — subsequent small calls also hung until the server was restarted. One bad/slow row wedged the entire server.

## Root cause
`src/tools/bulk-get.ts` already chunks + paces + classifies per-row errors, but there is **no overall hard deadline** on the call. Each sub-request relies on the bridge's per-request timeout (30s default) and `retryOnceOnTimeout`, but if a row's fe

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/98) · 2026-05-29 · closed · 0 comments

### P0: bulk_get trips PerimeterX CAPTCHA mid-batch — misclassified as generic error, no throttle/chunk

## Round-4 field report — P0

A 59-zpid `zillow_bulk_get` returned ~20 clean rows then 403'd the remaining ~39 with PerimeterX `px-captcha` denial pages. Three distinct defects:

### (a) CAPTCHA misclassified — the dangerous one
The retry-once-on-timeout from #78 does NOT catch this — it's an HTTP 403 with a CAPTCHA body, not a timeout. The row surfaces as a generic hard error, indistinguishable from "property not found." A caller seeing `resolved: false` can't tell "this home is gone" from "Zil

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/90) · 2026-05-28 · closed · 0 comments

### set keepAliveIntervalMs: 25_000 in FetchproxyServer constructor (fetchproxy#71)

## Parent issue

[fetchproxy#71](https://github.com/chrischall/fetchproxy/issues/71) — cohort follow-up to opt Pattern A MCPs into proactive keep-alive (0.9.0 wave).

## The change

In `src/transport-fetchproxy.ts` (or equivalent), add `keepAliveIntervalMs: 25_000` to the `FetchproxyServer` constructor options:

```ts
const transport = new FetchproxyServer({
  serverName: 'zillow-mcp',
  // ... existing options
  keepAliveIntervalMs: 25_000,  // Round-3 #67 — proactive SW resident-keeping
});
``

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/89) · 2026-05-28 · closed · 0 comments

### round-3 #8 (P2): description-honesty pass for resolvers

**Priority: P2**

## Real-world feedback

> Update tool descriptions for the behaviors confirmed this session:
> - \`zillow_get_by_address\`: document that \`search_fallback\` is often the ONLY rung that works for rural/remapped-locality addresses, and that passing a price band materially improves hit rate. (Right now the price params read as optional niceties; they're frequently load-bearing.)
> - \`zillow_resolve_addresses\`: until issue #1 lands, the description should warn that bulk is curre

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/80) · 2026-05-28 · closed · 0 comments

### round-3 #7 (P1): zillow_compare_properties still capped at 8 — raise to 25 or doc the bulk_get alternative

**Priority: P1**

## Real-world feedback

> \`zillow_compare_properties\` is still capped at 8 — I needed 3 batches for 19 properties this session. The prior prompt flagged this (onehome P1 #7 / cross-MCP #26); it doesn't appear to have been raised. Either raise compare to 25, or — better — point callers at the bulk_get endpoint for record fetching and reserve compare for genuine side-by-side. If bulk_get is the intended path for \"fetch N records,\" say so in the compare tool description and ha

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/79) · 2026-05-28 · closed · 0 comments

### round-3 #6 (P1): bulk concurrency overruns the bridge; timeouts misreport as resolved: false

**Priority: P1**

## Real-world feedback

> \`zillow_resolve_addresses\` fanned out hard enough to time out 7 of 20 sub-requests on the first call (\`fetchproxy ... did not respond within 30000ms\`); a retry cleared them. Redfin's bulk resolver did the same 20 with zero timeouts — so this is Zillow-MCP-specific fan-out tuning, not a universal bridge problem.
>
> **Fix: cap Zillow bulk internal concurrency to match Redfin's (~6 in flight), and add per-sub-request retry-once-on-timeout inside the 

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/78) · 2026-05-28 · closed · 0 comments

### round-3 #5 (P1): distinguish "resolved but no Zestimate" from "unresolved"

**Priority: P1**

## Real-world feedback

> A property can resolve to a valid zpid but have \`zestimate: null\`. This session, rows for 193 Downing Pl and 181 Highland Hts resolved fine but returned null Zestimate (181 had a rent Zestimate but no sale Zestimate). Downstream I had to special-case these so they didn't look like resolution failures.
>
> **Fix: on the property record add \`zestimate_status: \"available\" | \"unavailable\" | \"rent_only\"\` so callers can tell \"Zillow has no Zestima

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/77) · 2026-05-28 · closed · 0 comments

### round-3 #3 (P0): town/locality mismatch — city-scoped resolution silently misses ZIP-correct addresses

**Priority: P0**

## Real-world feedback

> Zillow files properties under a different municipality than the MLS/USPS city, and city-scoped resolution silently misses them. Real examples this session, all in the tracker's market:
> - \"212 Ridgeway Rd, Lake Lure\" → Zillow has it under **Rutherfordton**
> - Multiple \"Beech Mountain\" MLS addresses → Zillow files under **Banner Elk**
>
> The direct rung fails because it's implicitly city-scoped; only the unscoped price-band search found them.
>
>

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/75) · 2026-05-28 · closed · 0 comments

### round-3 #2 (P0): bulk resolver needs per-address price_hint for the search-fallback rung

**Priority: P0**

## Real-world feedback

> Bulk resolve has no way to pass the price hint that makes search-fallback work. The single get_by_address takes \`price_min\`/\`price_max\` to bound the search-fallback rung. The bulk resolver takes only addresses, so even once it runs the fallback rung (fix #1), it can't disambiguate. **Fix: let bulk resolve accept per-address optional price hints: \`[{address, city, state, zip, price_hint?}]\`. When \`price_hint\` is present, derive a ±0.5% band for 

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/74) · 2026-05-28 · closed · 0 comments

### round-3 #1 (P0, HEADLINE): zillow_resolve_addresses (bulk) doesn't run the same 3-rung strategy as zillow_get_by_address (single)

**Priority: P0 (HEADLINE)**

## Real-world feedback

> I handed the bulk resolver 20 addresses → all 20 came back \`resolved: false\`. I then called the SINGLE get_by_address on the same 20 (with price bands) → 17 resolved, every one via \`search_fallback\`. The bulk path is clearly only doing the direct-resolver rung and skipping the suffix-expansion + search-fallback rungs that the single call now has.
>
> **Fix: bulk resolve must run the identical 3-rung strategy (direct → suffix-expansion → 

[Read the thread](https://github.com/chrischall/zillow-mcp/issues/73) · 2026-05-28 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/chrischall/zillow-mcp/issues).