Skip to main content
Glama
chrischall

redfin-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Exhaustively sweep a Redfin map area

redfin_sweep_area
Idempotent

Enumerate every for-sale Redfin listing in a bounding box or ZIP list without truncation, recursively splitting capped map tiles and applying your filters locally.

Instructions

Enumerate EVERY for-sale Redfin listing inside a bounding box without silent truncation. Redfin's gis API returns at most 350 homes per call and ignores server-side filters, so this tool searches drawn-map polygons, recursively quarters any tile that hits the cap, dedupes by property_id and re-applies the caller's filters locally. Homes outside the box and tiles where Redfin drifted to another region are left out. Alternatively pass zips (ZIP mode) to sweep a list of ZIP regions instead of map tiles, when Redfin ignores drawn-map polygons. Returns a completeness summary (requests, tiles or ZIPs, unique listings, tiles/ZIPs still at the cap, drift warnings) plus the listings inline by default; pass the optional output_path to write them to a new JSON file instead, for large areas. Sequential requests with a delay. Read-only against Redfin; the only write is the optional local output file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
zipsNoZIP mode: sweep these ZIP regions instead of map tiles (fallback when Redfin ignores drawn-map polygons). Each ZIP is checked by the homes' own ZIPs; a ZIP that returns the 350-home cap is reported as capped.
boundsNoBox to sweep (lat/lng). Required unless `zips` is given.
beds_minNo
delay_msNoPause between requests (default 1200).
locationNoOptional city (e.g. "San Jose, CA") whose region lets the polygon probe try region-pinned request shapes.
baths_minNo
max_depthNoMax quarterings per tile (default 6).
price_maxNo
price_minNo
home_typesNo
output_pathNoOptional absolute path of a NEW JSON file to write the full results (and per-tile counts) to; a relative path or an existing file is refused rather than overwritten. Omit to get the results inline; use a file for large areas so the listings stay out of the conversation.
max_requestsNoHard request budget (default 120).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.1

TDQS

A4.6/5.0
Behavior5/5

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

Discloses a lot beyond the annotations: the 350-home API cap, recursive quartering, local dedupe by property_id, local re-application of filters, sequential requests with a delay, region-drift omissions, and refusal to overwrite an existing output file. It also resolves the readOnlyHint=false annotation by stating the only write is the optional local file, so there is no annotation contradiction.

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 purpose and the cap/recursion rationale, then mode selection, then output handling. It is a long paragraph, but nearly every clause carries operational information; a bit of it repeats (ZIP-as-capped restates cap logic already given).

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?

Covers the full calling picture for a 12-parameter, no-output-schema tool: how the sweep behaves, what it returns (completeness summary plus inline listings), and how to divert results to a file. Nothing essential is left to the schema.

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 coverage is only 58%, but the description compensates for the key gaps: zips vs bounds as alternative sweep modes, what the completeness summary counts, and the semantics of output_path (new file only, inline by default). Filters like beds_min/price_min and home_types get no direct explanation, though 're-applies the caller's filters locally' hints at their behavior.

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?

States a precise verb+resource ('Enumerate EVERY for-sale Redfin listing inside a bounding box') plus the defining quality (no silent truncation) that separates it from a normal search tool. The mechanism sentences make the tool's identity unambiguous even against the large sibling list.

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?

Explicitly says when to use ZIP mode vs map polygons ('when Redfin ignores drawn-map polygons') and when to pass output_path ('for large areas'). It does not directly name redfin_search_properties as the non-exhaustive alternative, which is the one routing decision an agent still has to infer.

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