Reads Zillow home listing details by URL, ZPID, street address, or ZIP code, returning price, Zestimate, facts, status, description, and listing agent information. Supports searches for homes for sale, for rent, or recently sold.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Zillow Listing Details MCP Server Get the price, Zestimate, and agent for ZPID 97531684"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for the Mamba Labs Zillow Listing Details actor on Apify. Read Zillow home details by URL, ZPID, address, or ZIP code.
Related MCP server: Zillow MCP Server
Give Zillow home URLs, ZPIDs, street addresses, or ZIP codes. You get one flat row per home with price, Zestimate, facts, and status, plus description and the listing agent shown on MLS listings when the home page is read.
All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:
{
"mcpServers": {
"mamba-zillow-listing-details": {
"command": "npx",
"args": [
"-y",
"@mambalabsdev/mcp-zillow-listing-details"
],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Restart the client. The read_zillow_listings tool appears.
Node.js 18 or newer.
An Apify API token from console.apify.com/account/integrations, set as APIFY_TOKEN. The server lists its tool without a token; a call needs one.
"What are the price, Zestimate, and listing agent of this Zillow home?"
"List the homes for sale in ZIP code 78701 with their facts."
"Which homes recently sold in 60614, and at what price?"
read_zillow_listings. One tool. Example arguments:
{
"listings": [
"97531684"
]
}Every buyer facing input of the actor. Omitted inputs take the actor's own defaults.
Input | Type | Required | Description |
| array | no | Zillow home URLs, ZPIDs, or street addresses, up to 1,000 per run. An address must include a street number and a city or ZIP code, and it must match the home Zillow returns, or you get a free row. |
| array | no | 5 digit US ZIP codes. Each returns the homes on Zillow's search pages for that ZIP code, up to Maximum listings. |
| string | no | for_sale (default), for_rent, or recently_sold. Used only with ZIP codes. |
| boolean | no | false (default) or true. With false, a ZIP code returns one search row per home at the search row price. With true, the actor reads each home's page at the listing row price, which adds the description and the listing agent. |
| number | no | The most homes to return in this run, across every input in order, from 1 to 1,000. Default 100. Text or a number. |
| string | no | Optional. The run stops before a charge that would pass this amount. Summary rows are always returned. |
Pay per event on Apify, billed to your Apify account. Prices in USD.
Event | Free plan | Bronze | Silver | Gold |
| $0.006 | $0.0057 | $0.0054 | $0.0051 |
| $0.002 | $0.0019 | $0.0018 | $0.0017 |
| $0.007 | $0.007 | $0.007 | $0.007 |
Blocked homes, missing homes, unreadable pages, and refused input are free. Mamba Labs pays the platform costs of the run, Apify proxy traffic included.
apify.com/mambalabs/zillow-listing-details
MIT. See LICENSE.
Read Zillow home details by listing URL, ZPID, or street address, or list homes by 5 digit ZIP code. Returns one flat row per home with price, Zestimate, beds, baths, area, status, and the listing agent shown on MLS listings. Blocked and missing homes are free rows. Costs 0.006 USD per home page read, 0.002 USD per ZIP code search row, plus 0.007 USD per run start.
| Name | Required | Description | Default |
|---|---|---|---|
| listings | No | Zillow home URLs, ZPIDs, or street addresses, up to 1,000 per run. An address must include a street number and a city or ZIP code, and it must match the home Zillow returns, or you get a free row. | |
| zip_codes | No | 5 digit US ZIP codes. Each returns the homes on Zillow's search pages for that ZIP code, up to Maximum listings. | |
| max_listings | No | The most homes to return in this run, across every input in order, from 1 to 1,000. Default 100. Text or a number. | |
| read_details | No | false (default) or true. With false, a ZIP code returns one search row per home at the search row price. With true, the actor reads each home's page at the listing row price, which adds the description and the listing agent. | |
| listing_status | No | for_sale (default), for_rent, or recently_sold. Used only with ZIP codes. | |
| max_charge_usd | No | Optional. The run stops before a charge that would pass this amount. Summary rows are always returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open-world, so the description focuses on what annotations can't say: exact per-row and per-run pricing, that blocked/missing homes cost nothing, and that max_charge_usd halts the run while still returning summary rows. That is materially useful pre-call context for an agent weighing cost against completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the two input modes, followed by return shape and then cost, which is the right order. The pricing sentence is dense and runs three amounts together, but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six optional parameters, no output schema, and a costly open-world read, the description compensates by describing the returned fields, the free-row cases, and the cost model per mode. An agent has enough to choose inputs and predict charges without opening anything else.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; however the description adds economic meaning the schema does not, tying read_details to the 0.006 vs 0.002 per-row price and to gaining description and agent data. It also frames the flat-row output that each parameter type produces.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (read) and resource (Zillow home details) and enumerates the three lookup modes (URL, ZPID, street address) plus the ZIP-search mode. It also states the return shape: one flat row per home with named fields. There is no sibling to confuse it with, but the scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the key operational tradeoff: read_details=false returns cheap search rows, while true reads each home page at the listing price and adds description and agent. It also scopes listing_status to ZIP-code use only and explains the free-row outcome for blocked/missing homes. What's missing is explicit when-not-to-use or prerequisite guidance, but for a single-purpose read tool this covers the decision points.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0read_zillow_listingsScored across 1 tool
With only one tool there is no risk of misselection between tools. However, that single tool internally conflates two distinct modes (ZIP-code search vs. single-home detail lookup), which the description explains but does not separate.
The lone name follows a clean verb_noun snake_case pattern (read_zillow_listings) and is descriptive of the domain. There is no second name to confirm a consistent convention, so it can't be a full 5.
A single tool is thin even for a narrow read-only domain; the search-by-ZIP and fetch-detail behaviors would more naturally be two tools. Agents also cannot opt into just a cheap ZIP search without invoking the same surface.
Lookup by URL, ZPID, and address plus ZIP search covers the core read workflows, and read-only is appropriate since Zillow is a data source. Gaps remain around filtering (price/beds ranges), pagination, and any bulk or comparison operations.
Zillow for-sale, for-rent and sold listings, and full property details, as structured JSON.
Zillow real estate listings for sale, rent, and sold, via an Apify Actor, hosted MCP.
Redfin for-sale, for-rent and sold listings plus full property pages, as structured JSON.
Zillow property details by link, zpid or address: Zestimate, rent Zestimate, tax value, agent.
