Zillow MCP Server
This server provides read-only Zillow access through two MCP tools: searching real estate listings and fetching full property details, all as structured JSON without needing a Zillow account.
Search listings (
hasdata_zillow_listing_getRealEstateListings): find for-sale, for-rent, or sold properties by location keyword with rich filters such as price, beds/baths, home type, square footage, lot size, year built, HOA, amenities, views, pet policy, days on Zillow, listing status, and sort order.Get property details (
hasdata_zillow_property_getPropertyDetails): fetch a single property by its Zillow URL to get the full page: list price, Zestimate and rent estimate, price history, tax history, beds/baths, living area, lot size, year built, home type, HOA, days on Zillow, description, features, photos, schools, walk/transit scores, and listing agent/broker info.Optional agent email extraction: enable
extractAgentEmailson the property tool to attempt pulling the listing agent's email address at an extra credit cost.Use cases: real-estate market dashboards, rental pricing analysis, agent lead lists, inventory tracking, valuation models, CMA generation, investor underwriting, rental yield analysis, and enriching buyer/seller agent assistants.
Provides read-only tools for searching Zillow listings (for-sale, for-rent, and sold) with rich filters, and for retrieving full property details such as price history, tax history, estimates, and schools.
Click on "Install 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 MCP ServerSearch for-sale homes in Austin, TX with 3+ beds under $600k, sorted newest first"
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.
Zillow MCP Server
A hosted Model Context Protocol (MCP) server that gives Claude, Cursor, Windsurf and any other MCP client two read-only Zillow tools. Search for-sale, for-rent and sold listings with rich filters, and read a single property in full, all as structured JSON, with no Zillow account and nothing to host.
It reads public listing pages on Zillow.com that a signed-out visitor can see.
https://mcp.hasdata.com/api/mcp?apis=zillow
Contents
Related MCP server: Zillow Working API MCP Server
What you need
An MCP client and a HasData API key from the dashboard, free to create with no card, and the trial covers about 200 calls at the 5-credit rate. This is a remote server, so the simplest path is a URL and an x-api-key header, with no container to run and no Zillow account anywhere in the flow. A client that only speaks stdio reaches it through a thin launcher, published as @hasdata/zillow-mcp on npm and hasdata-zillow-mcp on PyPI, shown below.
Quick start
The server URL is the same for every client. We run it hands-on in Claude Code and Claude Desktop. The other blocks follow each client's own documented format for a remote server.
Field | Value |
URL |
|
Transport | HTTP, streamable |
Auth header |
|
Clients with OAuth support can add the same URL as a connector and sign in without putting a key in a config file.
claude mcp add --transport http zillow "https://mcp.hasdata.com/api/mcp?apis=zillow" \
--header "x-api-key: HASDATA_API_KEY"Settings, then Connectors, then Add custom connector, then paste https://mcp.hasdata.com/api/mcp?apis=zillow and sign in.
For the config-file route, Claude Desktop loads only local (stdio) servers, so it reaches a remote server through a stdio launcher. The @hasdata/zillow-mcp package is that launcher, and it reads the key from the environment. Add this to claude_desktop_config.json:
{
"mcpServers": {
"zillow": {
"command": "npx",
"args": ["-y", "@hasdata/zillow-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}For Python instead of Node, swap the launcher for the PyPI package, which uvx runs without a manual install:
{
"mcpServers": {
"zillow": {
"command": "uvx",
"args": ["hasdata-zillow-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}~/.cursor/mcp.json for every project, or .cursor/mcp.json for one:
{
"mcpServers": {
"zillow": {
"url": "https://mcp.hasdata.com/api/mcp?apis=zillow",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}~/.codeium/windsurf/mcp_config.json. Windsurf calls the field serverUrl, not url:
{
"mcpServers": {
"zillow": {
"serverUrl": "https://mcp.hasdata.com/api/mcp?apis=zillow",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}.vscode/mcp.json in the workspace:
{
"servers": {
"zillow": {
"type": "http",
"url": "https://mcp.hasdata.com/api/mcp?apis=zillow",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}Example prompts
Prompts, not code. Paste one in and the agent picks the tool itself. Each is annotated with the calls it takes, because every successful call costs 5 credits.
Search for-sale homes in Austin, TX with at least three beds under $600k, sorted newest first, and give me the ten most recent with price and days on market.
One call, 5 credits. Price, beds, area and days on market come back on the search result.
Take the top result and pull its full detail: price history, tax history, the price estimate, and the assigned schools.
One call, 5 credits. Those live on the property page, which the details tool reads by URL.
Find for-rent condos in Austin that allow cats, then pull the rental estimate on the three cheapest.
Four calls, 20 credits. One search, then one property call for each of the three.
For this property URL, give me the list price, the price estimate, and the last three sales in its price history.
One call, 5 credits.
A search result is enough to rank and shortlist. Price history, tax history, the estimate, schools and the agent come from the property call, so a prompt that shortlists then inspects three homes is one search plus three property calls.
Tools
Two tools, read-only. Samples below are trimmed from real calls, and the numbers move as the market moves. Read them as shapes. Each tool name links to its endpoint reference, which carries the full field list.
The samples are the payload, not the whole response. A tools/call result carries one text block, and that text is itself JSON holding url, status, text and json, with the scraped data under json. From a raw JSON-RPC response the path is result.content[0].text, parsed, then .json. A chat client unwraps that for you and code talking to the endpoint directly does not.
Get Zillow real estate listings
hasdata_zillow_listing_getRealEstateListings
A page of listings by location keyword, filtered.
Parameter | Type | Required | Notes |
| string | yes | The location to search, such as |
| string | yes |
|
| number | Price band | |
| number | Bed and bath bands | |
| array |
| |
| number/string |
| |
| string |
| |
| number | Result page |
The reference also documents square-footage, lot-size, year-built and HOA bands, plus otherAmenities__, views__, pets__, listingType, propertyStatus__, listingPublishOptions__ and more.
Returns searchInformation with totalResults, a properties array, and pagination whose nextPage is the URL of the following page. Each property carries id, url, homeType, status, price, currency, a rentZestimate rental estimate, daysOnZillow, area in square feet, addressRaw and a structured address, latitude, longitude, beds, baths, listingDetails, mediaDetails and photos.
{
"id": "60134551",
"url": "https://www.zillow.com/homedetails/6116-Speyside-Dr-Austin-TX-78754/60134551_zpid/",
"homeType": "SINGLE_FAMILY",
"status": "FOR_SALE",
"price": 320000,
"currency": "$",
"rentZestimate": 2286,
"daysOnZillow": 0,
"area": 2277,
"address": { "street": "6116 Speyside Dr", "city": "Austin", "state": "TX", "zipcode": "78754" },
"beds": 4,
"baths": 3
}Get Zillow property details
hasdata_zillow_property_getPropertyDetails
One property in full, by its URL.
Parameter | Type | Required | Notes |
| string | yes | A Zillow property URL, the |
| boolean | Attempt to pull the listing agent's email. Adds 5 credits, so the property call costs 10 instead of 5 |
Returns the full page: price, currency, fees, beds, baths, area, yearBuilt, homeType, mlsId, a structured address and geo, the description and highlights, photos, schools, daysOnZillow, views, saves, an agentInfo block, and priceHistory, taxHistory and mortgage arrays. Zillow's own price estimate arrives in a zestimate object holding zestimate, an estimatedSaleRange and a rentZestimate. Read it as an estimate, not as a confirmed value.
areais an object here,{ livingArea, livingAreaUnits }, not the flat number the search tool returns. Readarea.livingAreafor the square footage on a property page, or a numeric comparison likearea > 2000silently fails against an object.
{
"id": 60134551,
"status": "FOR_SALE",
"price": 320000,
"currency": "USD",
"yearBuilt": 2002,
"beds": 4,
"baths": 3,
"area": { "livingArea": 2277, "livingAreaUnits": "Square Feet" },
"fees": { "monthlyHoaFee": "$500 annually" },
"zestimate": { "zestimate": 318100, "estimatedSaleRange": "$302K - $334K", "rentZestimate": 2286 },
"address": { "street": "6116 Speyside Dr", "county": "Travis County" },
"agentInfo": { "agentName": "Marie Coleman", "brokerName": "eXp Realty" },
"priceHistory": [{ "date": "2026-08-24", "price": 320000, "event": "listedForSale" }],
"schools": { "elementarySchool": { "name": "Bluebonnet Trail", "district": "Manor ISD" } }
}Errors and failure paths
Your client almost never sees an HTTP error code from a tool call. The MCP layer answers 200 and puts the failure inside the result, with isError set to true and the reason as text. The agent reads a message where you might expect a status line.
A wrong key surfaces as tool output, not as a failed connection. tools/list accepts any non-empty key and returns both tools, so the client completes its handshake and shows green. The first tool call then comes back with isError: true and the text HasData API error: 401 Unauthorized. Watch for that string, because nothing earlier in the flow reports the problem.
A missing key is the one real HTTP error. Authorization runs before any tool, and the connection itself fails with 401. CORS headers are present, and a browser client reads the status and not an opaque network failure.
An argument that breaks a tool's schema is rejected before it becomes a scrape. The server answers with isError: true and the text MCP error -32602: Input validation error, naming the offending field. Nothing is fetched and nothing is charged.
A search with no matches returns a successful result with an empty properties array, not an error. A location and filter set with no inventory still comes back with requestMetadata.status set to ok. Test for the array length before you iterate.
A property that has been delisted returns 400 with requestMetadata.status set to error. A URL from an old search can point at a listing that is gone.
Results that carry data also carry a requestMetadata.id worth quoting in support.
Pricing, free tier and limits
Each Zillow tool costs 5 credits per successful call. Turning on extractAgentEmails adds 5 credits to the property call, 10 instead of 5, so leave it off unless you need the email. Response size does not change the price.
The free trial is 1,000 credits over 30 days with no card, which is 200 Zillow calls at the base rate. After that an active account keeps getting 100 credits topped up each day whenever its balance drops below 100, so a low-volume agent runs on the free tier indefinitely.
Paid plans start at $49 a month for 200,000 credits, which is 40,000 calls. The unit price falls with volume, from $1.23 per 1,000 calls on the entry plan to $0.50 on Business, $0.42 on Growth and $0.37 on the largest high-volume plans.
Your plan also sets concurrency. The free trial allows 1 request at a time, Startup 15, Business 30, Growth 50, and the high-volume plans run from 200 to 1,500. Handle the overflow case defensively in anything unattended.
A request that comes back non-200 is not billed. A successful call that finds nothing is still a call.
Tool selection
The apis query parameter decides which tools your agent sees. Fewer tools means less context spent on tool definitions, and fewer chances for the model to reach for the wrong one.
?apis=zillow the two tools in this repo
?apis=zillow,redfin add Redfin real estate
?apis=zillow,google_maps add Google Maps placesThe parameter takes provider names like zillow and individual API names like zillow_listing. Misspelled names are ignored. If every name is wrong the request fails with 400, and the body lists both what it did not recognise and every valid value. Drop the parameter and the same endpoint exposes all 57 HasData tools.
How it compares
Zillow's own API programs are for members and partners moving their own inventory, such as the Bridge Interactive and Mortgage APIs, not a self-serve way to read the public market. For searching listings and reading arbitrary properties, scraping the public pages is the route, and this server does that behind a stable schema.
Zillow partner APIs | This server | |
Purpose | Move your own or MLS inventory | Read the public market |
Access | Membership or partner approval | One key and one URL |
Search across the market | Restricted | Yes, with rich filters |
Setup | Business onboarding | None |
Output | Partner feeds | Structured JSON, price and beds pre-parsed |
What this server does not do. No posting, no lead submission, no account data. It reads what a signed-out visitor can see on Zillow.com.
FAQ
Is there an official Zillow MCP server?
Zillow does not publish one. This one is maintained by HasData and reads public pages, which is why it needs no Zillow account.
What is a Zillow MCP server?
A server that exposes Zillow listing data as tools an AI client can call. The client sends a tool call over the Model Context Protocol, the server fetches the data and returns structured JSON, and the model works with the result. This one exposes two tools and runs remotely.
Do I need a Zillow account or API key?
No. The only credential is your HasData key. There is no Zillow membership to apply for, because the tools read public Zillow.com pages.
Why does a search result not show price history or schools?
Because Zillow does not put them on the search card. They live on the property page, which the details tool reads by URL. Search to shortlist, then call the property tool for depth.
What does the price estimate mean?
The zestimate object holds Zillow's own estimated value, a range around it, and a rental estimate. It is a model output, not an appraisal or a confirmed sale price. Treat it as an estimate.
Can I use this together with other HasData APIs?
Yes. The apis parameter takes a list, and ?apis=zillow,redfin gives your agent Zillow plus Redfin. Drop the parameter and you get everything.
Is HasData affiliated with Zillow?
No. HasData is an independent service and is not affiliated with, endorsed by, or sponsored by Zillow Group, Inc. Zillow is a trademark of its respective owner.
Compliance and personal data
HasData accesses publicly available data only. A platform's terms may restrict automated access, and you are responsible for your own compliance. Where the data you collect includes personal information, such as a listing agent's contact details, make sure you have a lawful basis for it under GDPR, CCPA or the equivalent rules in your jurisdiction.
HasData links
Product page and request builder | |
Server documentation | |
All 57 tools in one server | |
Client walkthroughs | |
Everything else we scrape | |
Plans and credit costs | |
Keys and usage | |
Node launcher on npm | |
Python launcher on PyPI |
Development
This repository is configuration and documentation for a remote server. There is no build step and nothing to containerize.
The tests in test/ assert the tool contract, the part that can break without a commit here. They check that ?apis=zillow returns exactly two tools, that every tool still declares its required parameters, that no name changed, and that the key in use is actually accepted. That last check calls a tool for real and costs 5 credits, which is the price of a canary that can fail for the right reason.
# macOS and Linux
HASDATA_API_KEY=your_key_here npm test
# Windows PowerShell
$env:HASDATA_API_KEY="your_key_here"; npm testThe same suite runs in CI on every push and once a week on a schedule, because the upstream tool list can change without anyone touching this repository. A failure means the tool list moved, the key stopped working, or the endpoint was unreachable, and the assertion message says which.
Contributing
Corrections to the tool tables and the response samples are the most useful contribution, because those are the parts that drift. Include the call you made and the response you got. Pull requests from forks run the suite without a key, and the live checks skip instead of going red.
License
MIT. See LICENSE.
Available Tools
2 toolshasdata_zillow_listing_getRealEstateListingszillow_listing: GET /AInspect
Get Zillow Real Estate Listings
Searches Zillow for-sale, for-rent, and sold listings by keyword with rich filters (price, beds, baths, home type, year built, lot/square footage, HOA, listing status, amenities, views, pet policy, days on Zillow) and pagination. Returns each listing with address, Zillow URL/zpid, price, Zestimate, beds/baths, sqft, home type, status, days on Zillow, coordinates, thumbnail, and listing agent. Use for real-estate market dashboards, rental pricing analysis, agent lead lists, inventory tracking, and collecting URLs for the Zillow Property endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| hoa | No | The Homeowners Association (HOA) fee. | |
| page | No | The page number of the results to retrieve. | |
| sort | No | The sorting option for the search results. | |
| type | Yes | The type of listing. | |
| pets__ | No | An array of pet options. | |
| keyword | Yes | The keyword used to search for listings. | |
| tours__ | No | An array of tour options. | |
| views__ | No | An array of views. | |
| keywords | No | Additional keywords to refine the search. | |
| beds_max_ | No | The maximum number of bedrooms. | |
| beds_min_ | No | The minimum number of bedrooms. | |
| basement__ | No | An array of basement options. | |
| baths_max_ | No | The maximum number of bathrooms. | |
| baths_min_ | No | The minimum number of bathrooms. | |
| moveInDate | No | The desired move-in date. | |
| price_max_ | No | The maximum price of the listing. | |
| price_min_ | No | The minimum price of the listing. | |
| homeTypes__ | No | An array of home types to filter the listings. | |
| listingType | No | The category of the listing. | |
| daysOnZillow | No | The number of days a listing has been on Zillow. | |
| lotSize_max_ | No | The maximum lot size. | |
| lotSize_min_ | No | The minimum lot size. | |
| mustHaveGarage | No | If set to true, only listings with a garage will be included. | |
| yearBuilt_max_ | No | The maximum year the property was built. | |
| yearBuilt_min_ | No | The minimum year the property was built. | |
| parkingSpotsMin | No | The minimum number of parking spots. | |
| singleStoryOnly | No | If set to true, only single-story properties will be included. | |
| squareFeet_max_ | No | The maximum square footage. | |
| squareFeet_min_ | No | The minimum square footage. | |
| otherAmenities__ | No | An array of other amenities. | |
| propertyStatus__ | No | An array of property statuses. | |
| hide55plusCommunities | No | If set to true, 55+ communities will be excluded. | |
| listingPublishOptions__ | No | An array of listing publish options. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden, and it does a good job by specifying both the search behavior and the returned data: 'address, Zillow URL/zpid, price, Zestimate, beds/baths, sqft, home type, status, days on Zillow, coordinates, thumbnail, listing agent.' It also states 'pagination' as part of the behavior. It does not cover rate limits or errors, but for a listing search this is largely background.
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?
The description is appropriately sized and front-loaded: it starts with the operation, then covers filters and return fields, then adds use cases. The prose is reasonably brisk for a 33-parameter tool, and most sentences earn their place; only a few phrases just echo the schema or the tool name.
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?
For a tool with 33 parameters, no output schema, and no annotations, this description is unusually complete. It covers what the tool searches, what filters are possible, what fields come back, how pagination works, and why someone would use it, plus it connects downstream to the sibling Property endpoint. An agent has what it needs to select and invoke the tool correctly.
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?
Input schema coverage is 100%, so every parameter already has a structured description. The tool description adds an organized summary of the main filter categories—'price, beds, baths, home type, day built, lot/square footage, HOA, listing status, amenities, views, pet policy, days on Zillow'—but it does not substantially promote per-parameter meaning beyond the schema.
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 opens with a specific verb and resource ('Get Zillow Real Estate Listings') and explicitly states it 'Searches Zillow for-sale, for-rent, and sold listings by keyword with rich filters'. It clearly distinguishes itself as a listing-search tool rather than a property-detail tool, and the closing note about 'collecting URLs for the Zillow Property endpoint' reinforces that distinction.
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?
The description provides concrete intended use cases: 'real-estate market dashboards, rental pricing analysis, agent lead lists, inventory tracking, and collecting URLs for the Zillow Property endpoint.' It gives a clear sense of when to choose this tool, though it does not explicitly name the sibling tool or state 'use getPropertyDetails when you already have a zpid.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hasdata_zillow_property_getPropertyDetailszillow_property: GET /AInspect
Get Zillow Property Details
Fetches the full Zillow property page by URL/zpid, with optional agent email extraction. Returns address, list price, Zestimate and Rent Zestimate, price and tax history, beds/baths, living area, lot size, year built, home type, HOA, days on Zillow, listing description, features/amenities, photos, school assignments, walk/transit scores, and listing agent/broker (plus email when enabled). Use for valuation models, CMA generation, investor underwriting, rental yield analysis, and enriching buyer/seller agent assistants with authoritative property data.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the property on Zillow. Must be a valid Zillow property URL. | |
| extractAgentEmails | No | If enabled, attempts to extract agent email addresses from the property details. Increases the cost of the request. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and it largely meets it. It discloses the rich return payload, the optional email extraction behavior, the note that email extraction increases cost, and that it treats the URL or zpid as the key. It does not discuss errors, auth, or rate limits, but for a read-style data fetch the behavior is otherwise well disclosed.
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?
The description is front-loaded with the core purpose and then uses a long, valuable list of return fields. It is information-dense but not bloated; each item supports an agent understanding of output. It is not as crisp as a two-sentence version, hence a 4 rather than a 5.
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?
Given that there is no output schema and no annotations, the description compensates by listing the major return categories, mentioning input composition, and naming target use cases. The agent can infer what a successful invocation yields. It does not fully specify failure modes or zpid format, but the essential call-and-response context is largely complete.
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 description coverage is 100%, so parameter meaning is already fully documented in the schema. The description adds mild context by framing extractAgentEmails as 'optional agent email extraction' and tying the URL to a full page fetch, but it does not substantially add syntax or domain meaning beyond the schema.
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 uses a specific verb ('Fetches') and a precise resource ('full Zillow property page by URL/zpid'), then enumerates the concrete data returned. It distinguishes itself from the sibling listing tool by focusing on a single property page rather than real estate listings, even though the sibling is not explicitly named.
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?
The description says exactly when to use this tool: 'Use for valuation models, CMA generation, investor underwriting, rental yield analysis, and enriching buyer/seller agent assistants.' This is clear context and use-case targeting. It does not explicitly exclude the sibling tool or state when not to use it, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
v1.0.0- First observed
hasdata_zillow_listing_getRealEstateListings - First observed
hasdata_zillow_property_getPropertyDetails
TDQS
The two tools have distinct jobs: one searches for listings and returns listing-level records, while the other fetches the full property page for a URL or zpid. The search tool also explicitly identifies itself as the entry point for the property endpoint, so an agent can assign each task easily.
Both names follow the same hasdata_zillow_entity_getThing pattern, so the set is predictable and readable. The minor inconsistency is that the verb portion is verbose and slightly redundant in different ways: getRealEstateListings versus getPropertyDetails, which makes them consistent but not perfectly parallel.
Two tools is at the borderline: the pair works well together as a search-then-details workflow, but the server is thin for a general-purpose Zillow data source. A property lookup by address or an agent lookup tool would make the count feel more complete.
The listing search plus property details covers the core real-estate data workflow: find properties, collect URLs, then fetch the full property record. The main gap is that agents cannot directly look up a property by address without first performing a keyword search, but that is a workaround through the existing search tool.
Maintenance
Related MCP Connectors
Zillow MCP for AI agents: property data, Zestimates & listings — 300+ fields per home. Free tier.
Zillow homes and agent contacts for AI agents — search by ZIP, by URL, or look up a zpid.
U.S. real-estate data: property records, AVM value + rent estimates, sale/rental listings.
One API for public web data across social, directories and real estate, as clean JSON.
Related MCP Servers
- AlicenseCqualityDmaintenanceEnables access to UK property listings, price estimates, agent information, and market data through the Zoopla API for searching properties for sale or rent with detailed filters and analytics.22MIT
- AlicenseCqualityDmaintenanceEnables access to Zillow real estate data through the Zillow Working API, allowing users to query property information and listings.1MIT
- AlicenseCqualityDmaintenanceEnables access to the Zillow56 API to search for real estate listings and rental market trends using locations, coordinates, or specific property filters. It also provides comprehensive housing market snapshots and historical data based on the Zillow Home Value Index (ZHVI).37MIT
- AlicenseNot gradedqualityFmaintenanceProvides real-time access to Zillow real estate data, enabling property search, details, Zestimates, market trends, and mortgage calculations via natural language.1448MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/HasData/zillow-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server