Skip to main content
Glama
chrischall

zillow-mcp

by chrischall

Resolve an address to its Zillow canonical URL + zpid

zillow_get_by_address
Read-onlyIdempotent

Resolve an address to Zillow's canonical URL and property ID (zpid), using smart fallbacks for rural and locality-mismatched addresses.

Instructions

Resolve a free-text address (with optional city/state/zip) to its Zillow canonical homedetails URL and zpid. IMPORTANT: for rural / mountain-MLS / locality-mismatched addresses (the search-fallback rung is often the ONLY rung that hits), ALWAYS pass price_min and price_max if you have any sense of the property's price band — without them the city/state search can't disambiguate and the call returns { resolved: false }. The price params are not optional niceties; they are frequently load-bearing. Tries up to 5 rungs: (1) direct resolver hit, (2) autocomplete typeahead — Zillow's own canonical address suggestions, whole-token street-matched then resolved to a zpid (high recall), (3) bidirectional street-token swap ("Rd" <-> "Road", "Hts" <-> "Heights", "Bluebird" <-> "Blue Bird"), (4) locality remap — city-drop + locality-alias substitution when the caller-supplied city fails (real-world cases: Lake Lure <-> Rutherfordton, Beech/Sugar Mountain <-> Banner Elk), (5) city/state search fallback bounded by the price band. Returns via: "direct" | "autocomplete" | "suffix_expansion" | "locality_remap" | "search_fallback" so the caller knows how the match was made; when the locality remap fires, queried_city (what you sent) and resolved_city (what Zillow returned) are both set so the caller can see the substitution. Degrades to { resolved: false } when ALL rungs miss — does not throw. Read-only, no auth required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
zipNoZIP code (e.g. "28746").
cityNoCity name (e.g. "Lake Lure").
stateNoTwo-letter state code (e.g. "NC").
addressYesStreet address (e.g. "126 Sleeping Bear Ln").
price_maxNoUpper bound for the search-fallback rung. Pair with `price_min` — same load-bearing role for rural/remapped-locality addresses.
price_minNoLower bound for the search-fallback rung. Frequently load-bearing: for rural / locality-mismatched addresses this is often the only rung that hits, and without a price band it cannot disambiguate. Pass it if you have ANY sense of the price band.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes beyond the annotations (readOnlyHint, openWorldHint, idempotentHint) by detailing the five resolution rungs, return fields (via, queried_city, resolved_city), and degradation behavior. It explicitly states it does not throw and is read-only, no auth. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but well-structured with clear sections (importance of price params, rung list, return fields). It is front-loaded with the core purpose. Some redundancy could be trimmed, but every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description explains return values (via, resolved, queried_city, resolved_city) and failure mode. It covers all 6 parameters thoroughly, including edge cases and real-world scenarios. The description is self-contained and complete for an agent to use effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, providing baseline 3. The description adds significant context: explains that price_min/price_max are not optional but load-bearing for disambiguation in search-fallback, with real-world examples (e.g., Lake Lure). It clarifies the role of each parameter beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool resolves a free-text address to a Zillow canonical URL and zpid, with a specific verb and resource. It distinguishes from sibling tools like zillow_get_property (which expects a zpid) and zillow_search_properties (which is broader search) by focusing on single-address resolution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use price_min and price_max, especially for rural/mountain-MLS addresses, calling them 'load-bearing'. It explains the fallback rungs and failure behavior. However, it does not directly compare this tool to sibling tools to guide selection between them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/chrischall/zillow-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server