Reported issues for homes-mcp

Pod holds 16 of 29 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 homes-mcp.

Most discussed

P2: confirm whether homes.com search reflects full market inventory or a partial (single-feed) feed

Summary

In a usage report, nearly all listings returned by homes_search_properties traced back to a single brokerage (Caulder Realty). This raises the question of whether homes.com's server-rendered search results reflect the full market inventory for a location, or a partial / single-feed slice (e.g. one brokerage's feed or a syndication subset).

Why it matters

If the search corpus is a partial feed, then:

"no listing found" / coverage conclusions drawn from search are

Read the thread · 2026-05-29 · closed · 2 comments

P2: healthcheck / auth-capture timeout is 120s — recommend a 15–20s probe with a clear "open & interact with a portal tab" message

Summary

The healthcheck / auth-capture flow currently waits up to 120s before giving up. That's far too long for an interactive probe: a user staring at a wedged call for two minutes has no signal about what to do. Recommend dropping the probe to a 15–20s budget with a clear, actionable message — e.g. "Open homes.com (or your portal tab) in your browser and interact with it (scroll/click), then retry." — so the failure mode is fast and self-explanatory.

Why

When the bridge is co

Read the thread · 2026-05-29 · closed · 0 comments

P1: add a first-class search-fallback resolver rung triggered on typeahead timeout/empty

Summary

When the structured smartsearch typeahead rung times out or returns empty, resolveOneAddress should fall back to homes_search_properties (city/zip search page) + a whole-token street match as a first-class rung, rather than only reaching the search-fallback after the slug rung has also been tried (and only on certain failure shapes).

Context

The resolver has three rungs: typeahead (primary) → slug → city/zip search-fallback. The search-fallback rung already exists (#47)

Read the thread · 2026-05-29 · closed · 0 comments

P0: single-address resolver + rung-fallthrough collapse a cold-bridge typeahead timeout into "no listing found"

Summary

homes_get_by_address (the single-address path) and the three-rung fallthrough in resolveOneAddress return { resolved: false, error: 'no listing found' } on a cold-bridge typeahead/SSR timeout — making a transport failure indistinguishable from a genuine miss.

This is a real-world false negative: a usage report concluded "homes.com has zero coverage" because homes_get_by_address("219 Picnic Point") returned resolved: false on a cold bridge. Re-running the same input war

Read the thread · 2026-05-29 · closed · 0 comments

Coverage: verify "no listing found" results are honest — homes.com indexes Lake Lure (repro blocked on #54)

Round-4 field report — coverage suspicion (parallel to compass #78)

Last session a 20-address homes_resolve_addresses call returned cleanly but with all rows no listing found — interpreted at the time as "that market genuinely isn't indexed." Chrome verification this session shows that interpretation is wrong: homes.com indexes Lake Lure NC with full detail pages.

Confirmed present on homes.com (verified via browser this session):

`155 Quail Cove Blvd Unit 1601, Lake Lure NC 2

Read the thread · 2026-05-28 · closed · 0 comments

P0: resolver hangs/times out on larger batches — needs chunking + per-request timeout + partial results

Round-4 field report — P0

homes_resolve_addresses hung for a full 4 minutes on a 60-address call, then died with "No result received… server may be unresponsive / crashed." A 20-address call to the same tool returned cleanly moments later. So this is batch-size-dependent hang, not a coverage issue.

This session it got worse: even a SINGLE-address homes_get_by_address call now times out (MCP error -32001: Request timed out) — reproduced twice on 155 Quail Cove Blvd Unit 1601 and

Read the thread · 2026-05-28 · closed · 0 comments

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

Parent issue

fetchproxy#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:

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

Read the thread · 2026-05-28 · closed · 0 comments

add search-fallback rung to homes_get_by_address (round-3 architectural gap)

Architectural gap

Round-3 zillow corpus made the case: a real-world set of 20 mountain MLS addresses resolved 0/20 via zillow's direct-resolver rung but 17/20 via the price-band-bounded search-fallback rung. The search-fallback rung was load-bearing, not the price band per se.

homes_get_by_address today runs one rung: slugify {address, city, state, zip} → GET /<slug>/ → parse JSON-LD. When the slug 404s or the page returns no listing JSON-LD — the failure mode rural/locality-m

Read the thread · 2026-05-28 · closed · 0 comments

Most recent

homes_get_by_address: investigate price_min/price_max — blocked on no search-fallback rung + unverified URL shape

Context

Round-3 review feedback flagged that zillow-mcp's zillow_get_by_address price_min/price_max parameters are "frequently load-bearing" — many rural and remapped-locality addresses resolve ONLY via the price-band-bounded search-fallback rung. Asked whether the same parameters could be added to homes_get_by_address for cross-site parity.

Investigation

Walked src/tools/by-address.ts, src/tools/resolve-addresses.ts, and src/tools/search.ts on origin/main (and on top of

Read the thread · 2026-05-28 · closed · 0 comments

bulk resolver should run the same fallback rungs as single-call (parity audit)

Round 3 feedback exposed that zillow_resolve_addresses was running only the direct-resolver rung while zillow_get_by_address had grown a 3-rung strategy (direct → suffix-expansion → search-fallback). Real example: 20 addresses → 0 resolved via bulk, 17 resolved when looped through the single call. Filed as chrischall/zillow-mcp#<TBD>.

This issue is the parity audit for homes_resolve_addresses against homes_get_by_address. Confirm or fix:

Does the bulk resolver run exactly the

Read the thread · 2026-05-28 · closed · 0 comments

P2: deprecate split history endpoint (get_property_history + get_tax_history); keep the combined one

Problem

Real-world report P2 item 24 verbatim:

"homes-com: get_property_history and separate get_tax_history overlap. Pick the combined endpoint, deprecate the split. The combined model is correct."

Currently homes-mcp exposes both homes_get_property_history and homes_get_tax_history as separate tools (src/tools/history.ts). The data overlaps, the surface is wider than it needs to be, and other MCPs in the family are converging on a single combined history endpoint.

Cha

Read the thread · 2026-05-27 · closed · 0 comments

P2: tool description honesty sweep

Motivation

Real-world session found many tool descriptions across the family of real-estate MCPs oversell or omit critical caveats. Examples (across the fleet, not all specific to homes-com):

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 a silent-wrong-match bug.
redfin_get_climate_risk mentions empty-on-missing but doesn't enumerate WHY data might be missing

Read the thread · 2026-05-27 · closed · 0 comments

P1: fetchproxy service-worker eviction handling

Problem

Real-world session blocked entirely on "extension icon needs to be clicked to wake service worker." Every homes-mcp tool call surfaced the same bridge_down error class because Chrome evicts the fetchproxy extension's service worker after ~30s idle.

This is a fleet-wide footgun across every fetchproxy-backed MCP (zillow, redfin, compass, homes-com).

Fix options (any combination)

Keep-alive ping from the MCP host every 25s while any fetchproxy-backed MCP is active (Chrome

Read the thread · 2026-05-27 · closed · 0 comments

P1: investigate rental signal feasibility (Homes.com has no rental data today)

Motivation

Real-world session found Homes.com exposes no rental signal at all — neither a Zillow-style inline rent_zestimate nor a Redfin-style comparable-rentals endpoint. STR (short-term rental) viability is half the buy/no-buy decision for vacation-market properties, so this gap matters for any tracker workflow.

This issue is investigate feasibility, not "add the endpoint" — start by checking whether Homes.com surfaces rent estimates anywhere we can scrape.

Investigation

Read the thread · 2026-05-27 · closed · 0 comments

P1: bundle history into homes_get_property via include_price_history + include_tax_history flags

Motivation

Real-world session needed homes_get_property + homes_get_property_history + homes_get_tax_history for most workflows. 3 separate tool calls × 53 properties = 159 unnecessary round trips.

Change

Add to homes_get_property input:

include_price_history: boolean (default false)
include_tax_history: boolean (default false)

When set, fetch the same data the dedicated tools return and inline it under price_history / tax_history on the response. Use server-si

Read the thread · 2026-05-27 · closed · 0 comments

P1: normalize event taxonomy on homes_get_property_history (events_normalized)

Motivation

Real-world session found every real-estate MCP exposes a price-history tool with a different schema. Standardize so callers don't re-implement N normalizers.

Standard shape

Expose events_normalized alongside the existing raw response:

events_normalized: [
  { date, type, price?, price_change_pct?, dom?, source_mls? },
  ...
]

with a shared type enum:

"Listed" | "PriceChange" | "Pending" | "Contingent" | "Sold" | "Withdrawn" | "Relisted" | "Delisted"

Read the thread · 2026-05-27 · closed · 0 comments

The remaining reports are on the project's issue tracker.