Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

zillow_search

Search Zillow listings by location, region ID, or map bounds and get normalized public results with status and paging filters.

Instructions

Search Zillow listings. Returns normalized Zillow public listing search results. Callers may pass a region id from autocomplete or a complete map bounding box. When a usable region-only response contains no listings, the API retries with a viewport from Zillow's public search page if that page selects exactly the same region. Upstream blocks and transport failures return errors.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
eastNoMap east bound; pass with west, south, and north
pageNo1-based page
westNoMap west bound; pass with east, south, and north
northNoMap north bound; pass with west, east, and south
southNoMap south bound; pass with west, east, and north
statusNoSearch context. Allowed values: for_sale (aliases sale, for-sale), for_rent (aliases rent, for-rent), sold
locationYesDisplay location
region_idNoZillow region id from autocomplete, used when complete bounds are not provided
region_typeNoZillow region type from autocomplete, used with region_id fallback

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.17.9
    • changedInput schema / properties / east / description
      Previous value: -"Map east bound from autocomplete"New value: +"Map east bound; pass with west, south, and north"
    • changedInput schema / properties / north / description
      Previous value: -"Map north bound from autocomplete"New value: +"Map north bound; pass with west, east, and south"
    • changedInput schema / properties / south / description
      Previous value: -"Map south bound from autocomplete"New value: +"Map south bound; pass with west, east, and north"
    • changedInput schema / properties / west / description
      Previous value: -"Map west bound from autocomplete"New value: +"Map west bound; pass with east, south, and north"
  2. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / status / enum
      Added value: +[
+  "for_sale",
+  "sale",
+  "for-sale",
+  "for_rent",
+  "rent",
+  "for-rent",
+  "sold"
+]
  3. Changed1 schema field changed
    • changedInput schema / properties / status / description
      Previous value: -"Search context: for_sale, for_rent, or sold"New value: +"Search context. Allowed values: for_sale (aliases sale, for-sale), for_rent (aliases rent, for-rent), sold"
  4. First observedv1.0.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the disclosure burden and does add real behavior: an automatic retry with a viewport when a region-only response returns no listings, and the fact that upstream blocks and transport failures surface as errors. It omits auth requirements, rate limits, or pagination behavior, but the fallback/error semantics are meaningful context beyond the schema.

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?

Purpose and return shape are front-loaded in the first sentence, with the retry caveat following. The retry sentence is long but earns its place as non-obvious behavior; nothing is redundant filler.

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 9-parameter read tool with full schema coverage and no output schema, the description covers purpose, both input modes, the empty-result retry fallback, and error behavior. Nothing essential for correct invocation appears missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all nine parameters including bounds pairing and status aliases. The description reinforces that region_id originates from autocomplete and that bounds must be complete, but adds little the schema lacks.

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?

States a specific verb and resource ('Search Zillow listings') and clarifies the return is normalized public listing search results. It is clear what the tool does, though it never explicitly names how it differs from siblings like zillow_property or zillow_autocomplete.

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

Usage Guidelines3/5

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

It implies two invocation modes (a region id from autocomplete or a complete map bounding box), which nudges the agent toward zillow_autocomplete for ids. However, it gives no explicit when-to-use/when-not guidance relative to zillow_property or other listing tools.

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