# 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](/mcp/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](https://github.com/chrischall/homes-mcp/issues/67) · 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](https://github.com/chrischall/homes-mcp/issues/66) · 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](https://github.com/chrischall/homes-mcp/issues/65) · 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](https://github.com/chrischall/homes-mcp/issues/64) · 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](https://github.com/chrischall/homes-mcp/issues/55) · 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](https://github.com/chrischall/homes-mcp/issues/54) · 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: 'homes-mcp',
  // ... existing options
  keepAliveIntervalMs: 25_000,  // Round-3 #67 — proactive SW resident-keeping
});
```

[Read the thread](https://github.com/chrischall/homes-mcp/issues/51) · 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](https://github.com/chrischall/homes-mcp/issues/47) · 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](https://github.com/chrischall/homes-mcp/issues/46) · 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:
1. Does the bulk resolver run *exactly* the

[Read the thread](https://github.com/chrischall/homes-mcp/issues/44) · 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](https://github.com/chrischall/homes-mcp/issues/31) · 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](https://github.com/chrischall/homes-mcp/issues/30) · 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](https://github.com/chrischall/homes-mcp/issues/29) · 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

- Che

[Read the thread](https://github.com/chrischall/homes-mcp/issues/28) · 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](https://github.com/chrischall/homes-mcp/issues/27) · 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"
```

Th

[Read the thread](https://github.com/chrischall/homes-mcp/issues/26) · 2026-05-27 · closed · 0 comments

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