Skip to main content
Glama
chrischall

zillow-mcp

by chrischall
OverviewSchemaSourceRelated ServersScoreDiscussions
TypeScript
Local

Resolve an address to its Zillow canonical URL + zpid

zillow_get_by_address
Read-onlyIdempotent

Resolve a free-text address to its Zillow property URL and zpid, even for rural or mismatched localities when you supply a price range.

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").
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact strips image/avatar URLs from the response; "full" returns Zillow's payload untouched. No field projection: this server has no verified record of which Zillow fields matter, and inventing one would risk dropping a field a caller needs.
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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv0.13.0
    • addedInput schema / properties / view
      Added value: +{
+  "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact strips image/avatar URLs from the response; \"full\" returns Zillow's payload untouched. No field projection: this server has no verified record of which Zillow fields matter, and inventing one would risk dropping a field a caller needs.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  2. First observedv0.11.1

TDQS

A4.3/5.0
Behavior5/5

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

The description is exceptionally transparent: it enumerates all five resolution rungs, explains the search-fallback behavior, states that it degrades to { resolved: false } rather than throwing, and discloses read-only/no-auth behavior beyond what the annotations say. There is no contradiction with the readOnlyHint, openWorldHint, or idempotentHint 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 longer than average but densely informative and well-structured: purpose, critical warning, numbered fallback rungs, return metadata, and failure behavior. Almost every sentence earns its place, though the price-param warning is emphasized twice in slightly redundant terms.

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?

For a complex tool with no output schema, the description is complete enough to call correctly: it explains the multi-rung algorithm, the role of price bounds, the via field values, the locality-remap fields, the no-throw failure contract, and the read-only/no-auth profile. An agent has sufficient information to know what will happen and what to pass.

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

Parameters4/5

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

The schema already has 100% parameter description coverage, so the baseline is 3. The description adds meaningful cross-parameter guidance: it clarifies that address is free-text, city/state/zip are optional, and that price_min and price_max are load-bearing for the fallback rung. This goes beyond individual schema descriptions, though some of the price guidance is redundant with the schema text.

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

Purpose4/5

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

The description clearly states it resolves a free-text address to a Zillow canonical homedetails URL and zpid, with a specific verb and resource. It does not explicitly differentiate itself from the similar-sounding zillow_resolve_addresses sibling, so it stops short of full sibling differentiation.

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 gives strong context on when the tool is appropriate: resolving a free-text address to a canonical URL and zpid. It also provides crucial usage guidance around price_min/price_max for rural or locality-mismatched addresses, but it does not explicitly state when to prefer this tool over alternatives like zillow_resolve_addresses or zillow_search_properties.

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