Skip to main content
Glama
Sign In
zillow-mcp

zillow-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get Zillow property details

zillow_get_property
Read-onlyIdempotent

Fetch a property's full Zillow record by zpid or homedetails URL, returning price, Zestimate, beds/baths, square footage, schools, features, and optional price/tax history.

Instructions

Fetch a property's full Zillow record by zpid (numeric Zillow Property ID, e.g. 12345) or by homedetails URL. Returns address (Zillow's slugged form), mls_street_address (canonical MLS form — prefer this when it disagrees), neighborhood, price, Zestimate, rent Zestimate, beds/baths, square footage, lot_size (sq ft) plus the derived lot_size_acres (round(lot_size / 43560, 2); both null — never 0 — for condos and listings with no lot), year built, schools, and an extracted_features block (lake_front, hot_tub, basement, furnished, dock, community) keyword-parsed from the description. Also returns zest_vs_list_pct — the list-vs-Zestimate spread, (price − zestimate) / zestimate × 100 rounded to 1 decimal: POSITIVE means listed ABOVE the Zestimate, negative below (null when either input is missing). The raw description is omitted by default — pass include_description: true to keep it; in most cases the extracted features cover what callers need. Price-history and tax-history are also opt-in (include_price_history: true / include_tax_history: true) — bundle them in to skip a separate call. Provide exactly one of zpid or url. Read-only; safe to call repeatedly.

Input Schema

NameRequiredDescriptionDefault
urlNoA Zillow homedetails URL (or path beginning with /homedetails/)
zpidNoZillow Property ID (numeric)
include_descriptionNoInclude the raw `description` in the response. Defaults to `false` — `extracted_features` is always populated and usually sufficient.
include_tax_historyNoInclude the tax-history series (mirrors `zillow_get_tax_history`) on the response under `tax_history`. Defaults to `false`.
include_price_historyNoInclude the price-history series (mirrors `zillow_get_price_history`) on the response under `price_history`. Defaults to `false`. Saves a round trip when you already know you want the full picture.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.4
    • changedInput schema / properties / zpid / anyOf
      Previous value: -[
-  {
-    "exclusiveMinimum": 0,
-    "maximum": 9007199254740991,
-    "type": "integer"
-  },
-  {
-    "type": "string"
-  }
-]New value: +[
+  {
+    "exclusiveMinimum": 0,
+    "maximum": 9007199254740991,
+    "type": "integer"
+  },
+  {
+    "pattern": "^\\d+$",
+    "type": "string"
+  }
+]
  2. Changed1 schema field changedv1.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. First observedv0.11.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description adds substantial non-obvious behavior: the raw `description` is suppressed by default, price/tax history are opt-in, lot_size_acres is a derived rounded field that is null (never 0) for condos. It also pins down the sign convention of zest_vs_list_pct, which is exactly the kind of trap an agent would otherwise get wrong.

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?

Information-dense but front-loaded: the identifier options come first, then return contents, then the opt-in flags. Given there is no output schema, explaining the return payload here is earned rather than filler; the only mild duplication is restating the include_description default that the schema already states.

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?

With 5 parameters, no output schema, and heavy derived-value logic (lot_size_acres, zest_vs_list_pct, extracted_features), the description carries the full burden and does so: it documents return shape, defaults, null semantics, and the one-of identifier rule. Nothing an agent needs to call it correctly is missing.

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?

Schema description coverage is 100%, so the schema baseline is 3, but the description adds real meaning on top: why include_description defaults to false, what each history flag mirrors, and that bundling them saves a round trip. The one gap is `url`, whose accepted formats are only documented in the schema, not the description.

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?

Opens with a specific verb+resource ('Fetch a property's full Zillow record') and names both accepted identifiers (zpid or homedetails URL). It also enumerates the returned fields, which lets an agent distinguish it from siblings like zillow_get_by_address, zillow_search_properties, or the history tools without opening any schema.

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?

Gives a hard calling constraint ('Provide exactly one of zpid or url') and a clear decision rule for the opt-in flags ('bundle them in to skip a separate call'), naming the sibling calls they mirror. It does not, however, explain when to reach for this tool versus zillow_get_by_address or zillow_search_properties, so routing among the retrieval siblings is left to inference.

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

Deploy Server

Other Tools