zillow

Look up real-estate listings, property details, Zestimates, saved searches/homes, and market reports on Zillow via MCP. Triggers on phrases like "find homes in", "what's the Zestimate for", "show my saved Zillow homes", "what's my saved Zillow search seeing", "what does Zillow say about", "Zillow market report for", or any request involving Zillow properties, prices, or your saved Zillow activity. Requires zillow-mcp installed and the ContextMint Bridge extension active (see Setup below).

zillow-mcp

MCP server for Zillow — natural-language access to listings, property records, Zestimates, your saved searches/homes, and market reports. Routes through your signed-in zillow.com tab via the ContextMint Bridge browser extension, so Akamai sees a real browser session instead of a Node process.

• npm: npmjs.com/package/zillow-mcp
• Source: github.com/chrischall/zillow-mcp

⚠️ Zillow does not publish a public consumer API. This server uses the same private endpoints the zillow.com web app calls, dispatched through your own signed-in browser tab via the ContextMint Bridge extension. Use at your own discretion.

Setup

1. Install zillow-mcp

.mcp.json (project) or ~/.claude/mcp.json (global):

json

{
  "mcpServers": {
    "zillow": {
      "command": "npx",
      "args": ["-y", "zillow-mcp"]
    }
  }
}

2. Install the ContextMint Bridge extension (one-time, shared across all fetchproxy-based MCPs)

Get it from the ContextMint Bridge releases:

• Chrome: download the Chrome zip, unzip it, then chrome://extensions → Developer mode → Load unpacked → pick the unzipped folder.
• Safari: not available yet — it will ship inside the ContextMint app, which has no public download. Use Chrome for now.

ContextMint Bridge is the renamed fetchproxy extension from the same maintainer (source: nullnet-app/contextmint-bridge); build it yourself or verify the zip with shasum -a 256 -c contextmint-bridge-chrome-<version>.zip.sha256.

3. Open zillow.com and sign in.

That's it. No API keys, no env vars.

Tools

Public data

• zillow_search_properties — Search by location + filters (price, beds, home type, status). Returns matching listings with price, Zestimate, beds/baths, sqft, image, and homedetails URL. Pass include_meta: true to see Zillow's own total and whether the answer was truncated.
• zillow_sweep_area — Every listing matching the filters in an area, not just the first pages: tiles the map until no tile is truncated and reports whether the sweep is complete. Use it when the user needs the whole inventory ("all 3-bed townhomes under $900k in this county"); pass output_path for large areas.
• zillow_get_property — Full property record by zpid or homedetails URL. Returns address, price, Zestimate, rent Zestimate, beds, baths, sqft, year built, schools, price history.
• zillow_get_zestimate_history — Time series of Zestimate values for a property.
• zillow_get_market_report — Median sale/list/rent price, days on market, inventory, ZHVI for a Zillow region (e.g. /home-values/6181/brooklyn-ny/).
• zillow_calculate_mortgage — Local PITI calculator. No network call. Provide home price, interest rate, optional down payment / taxes / insurance / HOA / PMI; returns a full monthly breakdown.

Signed-in user data (the unique value vs. Bridge-API competitors)

• zillow_get_saved_searches — Your saved searches, with new-listing counts and notification frequency. view: "brief" answers one line per search (name — <last update> — <N new | no new listings | new count unknown>).
• zillow_get_saved_homes — Homes you've favorited.

Response shape (view)

Three of this server's twenty tools take view: "compact" | "full" — zillow_search_properties, zillow_get_by_address and zillow_resolve_addresses — and on all three compact is the DEFAULT. The slim rung is what you get without asking for it.

Compact here is media stripping, not a field projection. src/view.ts writes no field list, because this repo holds no captured Zillow payload from which one could honestly be derived. It removes keys whose value is a picture plus bare image URLs, which is subtractive and so cannot drop a field nobody knew about.

image_url is KEPT — the opposite of what "compact strips media" implies

Read that again before you plan around it. A listing's image_url survives compact, on purpose, via an explicit keep rule.

It is not incidental decoration: search.ts DERIVES it, off photos or responsivePhotos depending on which page shape Zillow served, so that a single-address hit carries an image like a real search hit does. That is a field choice made with knowledge of the API, and the blind subtractive rule must not overrule it. If you want the whole gallery, zillow_get_property_photos is the tool.

The consequence is worth stating plainly, because it will otherwise look like the parameter is broken: image_url is the ONLY media field a formatted listing carries, so today compact and full serialise to the SAME BYTES on all three tools. formatListing sets image_url from imgSrc on a real search hit and from firstPhotoUrl on an adapted homedetails hit, and every other key on the record is an address, a number, or the homedetails url — which is a page, not a picture, and which the rule already leaves alone.

So view on these three is a wiring contract, not a saving you can measure yet: it starts mattering the moment a media field is added to the listing shape. (A repo test pins the wiring for exactly this reason — because the output cannot tell an honoured view from an ignored one, a regression here would look like nothing at all.)

view: "full" returns the formatted record untouched. There is deliberately no raw rung: nothing here re-serialises Zillow's payload after formatting, so full already IS what the tool built, and a third value would silently alias one that exists.

zillow_get_saved_searches takes a different view, "full" | "brief" (full is the default): brief is the context-groups line (see below), not a media rung.

Why the other sixteen have none

• zillow_get_property_photos — its PRODUCT is the image. Stripping media there would not shrink the response, it would empty it. This tool is the canonical example in the shared helper's own documentation of where the rule must never be applied.
• zillow_get_property already IS a hand-written field projection: the raw description, price_history and tax_history are opt-in (include_*), and extracted_features is derived. A second projection on top would fight the first.
• zillow_bulk_get and zillow_compare_properties are built out of that same formatted record, so they inherit its projection rather than needing their own.
• zillow_get_price_history, zillow_get_tax_history, zillow_get_zestimate_history, zillow_get_market_report answer with hand-shaped series and metrics — dates and numbers. There is no picture in a time series.
• zillow_calculate_mortgage, zillow_calculate_affordability, zillow_estimate_rent_vs_buy make no network call at all. They compute from your inputs, so there is no upstream payload to project.
• zillow_get_saved_homes answers with hand-shaped records of your own saved activity. Note that a saved home carries a constructed image_url too, from imgSrc — consistent with the three tools above, and returned unconditionally here.
• zillow_register_session, zillow_set_active_session, zillow_get_session_context answer with a receipt or with session state.
• zillow_healthcheck answers with a bridge diagnostic.

Passing view to one of those is not an error and will not fail: the tool does not declare it, so zod drops the unknown key and the call runs exactly as it would have. Nothing warns you, so a successful call is not evidence the rung was honoured.

In context groups

zillow-mcp is a member of the home group (mcp-host context groups; every tool except zillow_healthcheck carries _meta.mint with domain: "home").

• Canonical read: zillow_get_saved_searches answers what's new — "anything new on my saved searches?" — with view: "brief", one line per search: name — <last update, ISO date | no date> — <N new | no new listings | new count unknown> (new count unknown when Zillow omits a search's new-listing count — it is not a claim that nothing is new). No saved searches answers the single note line -- none, and a search whose own name starts with -- or \ is escaped with one leading \ so it never reads as a note. It takes no date range and declares no subject: a saved search is a query, not a person, property or account, so there is no listable set to publish as an enum.
• Nothing here answers what's due or what's on; every other read is a lookup (search, property, history, market), the calculators and session tools are other.
• A compound ask looks like "what's new at home — any new listings on my saved searches, and is the pool heater on?": the group fans out to this canonical read beside the other home members' and reads back one line each.
• Browser-bridged: every call rides the signed-in zillow.com tab through the ContextMint Bridge, so when the browser is not open (or the extension is not connected) the group answers that Zillow needs your browser open rather than an empty list.

Trigger examples

• "Find me 2-bedroom condos under $1.5M in Brooklyn" → zillow_search_properties
• "What's the Zestimate on 123 Main St?" → resolve to zpid, then zillow_get_property
• "How has the Zestimate for zpid 12345 changed?" → zillow_get_zestimate_history
• "What's new on my saved Zillow searches?" → zillow_get_saved_searches
• "Pull up my saved homes on Zillow" → zillow_get_saved_homes
• "Brooklyn real-estate market trends" → zillow_get_market_report
• "Monthly payment on a $500k home, 20% down, 6.5% rate" → zillow_calculate_mortgage

Gotchas

• Sign-in required for saved- tools.* If the user isn't signed into zillow.com in the bridged Chrome tab, those tools fail with SessionNotAuthenticatedError. Public tools work either way, but signed-in sessions are more reliable against captcha walls.
• Captcha interstitial. Zillow occasionally serves a captcha to fresh sessions. Solving it in the Chrome tab once unblocks subsequent fetches.
• No write surface yet. All tools are read-only. Saving a home / search / contact form are not implemented in v0.1.