Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

zillow_search

Search Zillow listings by location, region ID, or map bounds; filter by sale, rent, or sold status to retrieve property search results.

Instructions

Search Zillow listings. Returns Zillow 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 search page if that page selects exactly the same region. Upstream blocks and transport failures return errors.

Input 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.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does usefully disclose a fallback retry (region-only empty response retried via a Zillow viewport) and that upstream blocks/transport failures return errors. It omits auth requirements, rate limits, and pagination behavior even though a 'page' parameter exists, leaving meaningful gaps.

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?

Front-loaded with the core purpose, followed by return, input modes, and error/retry behavior. Four sentences, each roughly earning its place, though the retry sentence is somewhat convoluted.

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

Completeness4/5

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

For a search tool with no output schema and no annotations, the description covers purpose, two input modes, a fallback retry, and error behavior. It is reasonably complete, though pagination and how the status enum shapes results could be clearer.

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 9 parameters including bounds, status aliases, and region_id/region_type fallback. The description reinforces the region_id-vs-bounding-box distinction but adds no format or value semantics beyond what the schema provides.

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+resource ('Search Zillow listings') and describes the return ('Zillow listing search results'). It's clearly a search tool, distinguishable from zillow_property and zillow_autocomplete in spirit, but it never names or differentiates against those siblings explicitly.

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?

'Callers may pass a region id from autocomplete or a complete map bounding box' implies usage context for the two input modes, but there is no explicit when-to-use guidance versus alternatives like zillow_autocomplete or zillow_property, and no exclusions.

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