# Reported issues for compass-mcp

Pod holds 18 of 35 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 [compass-mcp](/mcp/compass-mcp).

## Most discussed

### Cohort: resolve via structured address fields (address/city/state/zip) against the typeahead API, not free-text ?q= SSR

## Round-4 directive (cohort-wide)

All five realty MCPs should resolve addresses using **structured fields** (address, city, state, zip) against the portal's typeahead/autocomplete API — not by flattening to a free-text `?q=<blob>` string against an SSR page.

## Why (this is also the fix for the coverage false-negatives)
Compass #78 and homes #55 are silent false-negatives for listings the portals **do** have. Investigation this session:
- compass.com's SSR free-text paths (`/search/?q=…`, `/h

[Read the thread](https://github.com/chrischall/compass-mcp/issues/79) · 2026-05-28 · closed · 1 comment

### feat(by-address): add price-band-bounded search-fallback rung

## Context

Round 3 cross-MCP feedback proved that zillow's `price_min`/`price_max` is "frequently load-bearing" on `zillow_get_by_address` — many rural / remapped-locality addresses resolve ONLY via the price-band-bounded search-fallback rung. Same feedback flagged compass as also lacking price-band.

Investigation in `/tmp/compass-priceband` (branch `feat/priceband-investigate`) concluded **this is NOT a low-effort change** for compass and is filed as its own design issue rather than shipped s

[Read the thread](https://github.com/chrischall/compass-mcp/issues/70) · 2026-05-28 · closed · 1 comment

### raise compass_compare_properties cap from 8 → 25, or add bulk endpoint

From the real-world cross-MCP report (P2 #26).

## Motivation

Today's 53-listing session needed many sequential round trips through compare_properties (max 8 per call). Raising the cap or adding a bulk endpoint cuts that to 2-3.

## Two options

**A. Raise `compass_compare_properties` cap from 8 to 25.** Lower-effort. Same tool surface; same concurrent fan-out shape as today.

**B. Add `compass_bulk_get` (covered by the bulk_get issue).** A real bulk endpoint that returns structured records ONL

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

### surface listing_agent_history (other listings by the same agent)

From the real-world cross-MCP report (P2 #25).

## Motivation

Compass is positioned as the **agent-rich source** of the five MCPs — lean into that. Useful for assessing a realtor's track record before a showing, spotting bulk listers, or identifying the dominant agent in a micro-market.

## Change

Add `listing_agent_history` to property records (or a dedicated `compass_get_agent_history(agent_id)` tool):

```
listing_agent_history: {
  agent_id,
  agent_name,
  active_listings_count,
  recentl

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

### tool description honesty sweep (especially compass_get_by_address silent-wrong-match)

From the real-world cross-MCP report (P2 #23).

## Motivation

Many tool descriptions oversell or omit critical caveats. Real examples from today:

- **`compass_get_by_address` doesn't mention the silent-wrong-match bug** (see the CRITICAL bug issue) — this is the highest-priority description fix until the underlying bug ships, because any caller trusting the current description gets silently corrupted data.
- `compass_search_properties` may have an undocumented result cap (see the search-cap au

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

### normalize event taxonomy on compass_get_price_history (events_normalized)

From the real-world cross-MCP report (P1 #11).

## Motivation

Today every MCP exposed `get_price_history` with a different schema:

- **Compass**: parallel `events` (current listing) + `history` (prior listings) arrays — note: report observes Compass already returns most of this inline on `get_property`, which is good.
- Zillow: single time series with MLS attribution + price-change %
- Redfin: `price_events` + `tax_events` returned together
- homes-com: combined endpoint + separate one

## Cha

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

### add bulk compass_resolve_addresses(addresses[])

From the real-world cross-MCP report (P0 #4).

## Motivation

Today's session 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 collapses this to one round trip.

## Change

Add `compass_resolve_addresses(addresses: string[])` that takes an array and returns:

```
[
  { address, resolved, url, pid, listing_id_sha, confidence },
  ...
]
```

Compute concurrently server-side.

## Coupling

Must u

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

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

Mirrors chrischall/onehome-mcp#25.

## Motivation

Today's session has an ongoing "109 vs 169 Overlook Point Ln" discrepancy between Compass and Canopy MLS for the same listing — Compass says 169, Zillow + Canopy MLS + Redfin say 109. Better data plumbing might have flagged it sooner.

## Fix

If the upstream MLS payload has alternate address strings (different MLS feeds, prior addresses, parcel variants), surface them as `address_alternates: string[]` on the formatted record. Omit the field whe

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

## Most recent

### P1-3: compass_search_properties pagination cursor does not advance (offset ignored; only first ~41 reachable)

## Summary

`compass_search_properties` reports e.g. `total_items: 104` and returns `next_offset: 40`, but calling again with `offset: 40` returns the **identical first batch**. The SSR `search_path` shows `page-9` yet the payload is page 1, so only the first batch of results is ever reachable.

## Investigation (live, via the bridge)

- Real SSR page size is `num: 41` (from `initialResults.rawLolSearchQuery`), **not 5** — the `COMPASS_PAGE_SIZE = 5` constant in `src/tools/search.ts` is wrong. W

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

### P1-2: add compass_search_properties fallback rung to the address resolver (typeahead timeout/empty)

## Summary

When the structured typeahead rung times out or returns empty, the resolver should fall back to a `compass_search_properties`-style locality search with a whole-token street match as a **first-class resolver rung** — search has far better recall than typeahead.

## Rationale

The typeahead (`/api/v3/omnisuggest/autocomplete`) is the primary rung (#78/#79), but on a cold bridge it times out, and even when healthy it can miss rural/locality listings. `compass_search_properties` walks t

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

### P0-2: compass_resolve_addresses misclassifies transport timeout as resolved:false (false 'no listing found')

## Summary

`compass_resolve_addresses` returns `resolved: false` when a cold-bridge typeahead round-trip times out at the transport layer. That outcome is **indistinguishable from a genuine no-match**, so a caller cannot tell "Compass has no listing here" apart from "the bridge timed out before it could ask."

## Impact

A 60-address resolve workflow produced a false conclusion that "Compass covers only 4/60" for a Lake Lure, NC batch. A subsequent `compass_search_properties` call proved 40+ La

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

### P0: by-address returns false-negative for listings Compass actually has (silent under-report)

## Round-4 field report — NEW P0 (silent under-report)

`compass_get_by_address` returns `{ resolved: false, error: "no listing matched the address" }` for listings that Compass **does** have, Active, indexed, in a market Compass serves. This is the inverse of the #45 silent-wrong-match bug — and the same dangerous failure class: a downstream tracker treats "Compass doesn't have it" as truth and drops a real listing.

## Reproduced end-to-end this session
Both return `resolved: false` from the M

[Read the thread](https://github.com/chrischall/compass-mcp/issues/78) · 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: 'compass-mcp',
  // ... existing options
  keepAliveIntervalMs: 25_000,  // Round-3 #67 — proactive SW resident-keeping
});
`

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

### add search-fallback rung to compass_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.

`compass_get_by_address` today runs **one rung**: a single `/homes-for-sale/?q=<freetext>` SSR fetch with `addressMatchesQuery` verify. When the free-text search returns no match — the failure mode rural/locality-

[Read the thread](https://github.com/chrischall/compass-mcp/issues/71) · 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 `compass_resolve_addresses` against `compass_get_by_address`.** Confirm or fix:
1. Does the bulk resolver run *exactly*

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

### fetchproxy service-worker eviction handling

From the real-world cross-MCP report (P1 #22).

## Problem

Today's session blocked entirely on "extension icon needs to be clicked to wake service worker." Every Zillow, Redfin, Compass, and homes-com tool surfaced the same `bridge_down` error class. Chrome evicts the fetchproxy service worker at ~30s idle.

## Options (pick one or layer them)

- **Keep-alive ping** from the MCP host every 25s while any fetchproxy-backed compass tool is active (stay under the 30s eviction window).
- **Lazy-revi

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

### add compass_get_comparable_rentals or other rental signal

From the real-world cross-MCP report (P1 #19).

## Motivation

Zillow has `rent_zestimate` inline on every property. Compass currently exposes **no rental signal at all**. STR (short-term rental) viability is half the buy/no-buy decision for vacation-market properties (Lake Lure / mountain NC today, but applies to every vacation market).

## Change

Add at least one of:

1. **`compass_get_comparable_rentals(pid)`** — returns nearby active and recently-rented comps with monthly rent, beds/baths, 

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

### check compass_search_properties for silent result cap

From the real-world cross-MCP report (P0 #5).

## Problem

`zillow_search_properties` silently caps at ~44 results regardless of `limit` parameter — today's session passed `limit: 200` for Lake Lure NC and got 44. Audit `compass_search_properties` for the same failure mode.

## Investigation

1. Run a Compass search known to have >100 results (e.g. Charlotte NC) with `limit: 200`.
2. Compare returned count vs `limit` vs the count visible in the Compass UI.
3. If a silent cap exists, identify the

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

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