Skip to main content
Glama
chrischall

redfin-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get Redfin property details

redfin_get_property
Read-onlyIdempotent

Retrieve a complete Redfin property record by URL, property ID, or listing ID. Returns address, beds/baths, sqft, price, status, and more for any listing.

Instructions

Fetch a property's full Redfin record. Provide one of: (a) url — full Redfin homedetails URL or path, resolved via the initialInfo endpoint; (b) property_id alone — resolved internally by following Redfin's /home/ redirect to the canonical listing, then initialInfo; or (c) property_id + listing_id — fastest, skips resolution and goes straight to aboveTheFold. Returns address, beds/baths, sqft, lot_size (sq ft), year built, price, status, days on market, plus derived fields (lot_size_acres, price_drop_*, hoa_monthly_usd, last_sold_*, tax_annual, extracted_features). lot_size / lot_size_acres are null (never 0) for condos and listings with no public-records lot. primary_photo_url is a raw Redfin CDN URL and is dropped on the default compact view — pass view: "full" for it, or use redfin_get_property_photos for the whole gallery. The raw marketing description is OMITTED by default — opt in with include_description: true. Set include_price_history: true to bundle the full price history (and the cross-MCP-normalized events_normalized view) inline; set include_tax_history: true for tax_history. Read-only; safe to call repeatedly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoRedfin homedetails URL or path (e.g. /NY/Brooklyn/42-Monroe-St-11238/home/40732555)
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 Redfin's payload untouched. No field projection: this server has no verified record of which Redfin fields matter, and inventing one would risk dropping a field a caller needs.
listing_idNoNumeric Redfin listing ID. Optional; pairs with property_id to skip resolution.
property_idNoNumeric Redfin property ID. Sufficient on its own — when no listing_id/url is given it is resolved internally via the /home/<id> redirect. Pair with listing_id to skip that resolve step entirely.
include_descriptionNoInclude the raw marketing/public-remarks description string in the response. Default false to save context — `extracted_features` always carries the structured signal callers actually need.
include_tax_historyNoBundle the full tax history inline as `tax_history`. Default false. (#49)
include_price_historyNoBundle the full price history inline as `price_history` + `events_normalized`. Default false. Saves a follow-up redfin_get_price_history round trip — use this when a workflow needs both. (#49)

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
  2. Changed1 schema field changedv0.13.1
    • 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 Redfin's payload untouched. No field projection: this server has no verified record of which Redfin fields matter, and inventing one would risk dropping a field a caller needs.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  3. First observedv0.10.1

TDQS

A5/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses concrete data-shape behavior: lot_size null for condos never 0, primary_photo_url dropped on compact view, raw marketing description omitted by default, and derived-field additions (events_normalized for price history). It also explicitly confirms read-only safety, reinforcing the annotations without contradicting them. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Though the description is long, every sentence carries actionable detail — resolution mechanics, output fields, edge cases, and opt-in flags. It is front-loaded with the core purpose and input routes, and the subsequent clauses each add a distinct behavioral fact. No filler, no restatement of the title, and no redundancy with the schema.

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 no output schema, the description must specify the return shape itself, and it does: it enumerates address, beds/baths, sqft, lot_size, year built, price, status, days on market, and a set of derived fields, plus the exact null behavior for condos. It also covers conditional output (photo drop, description omission) and how to enable them. Given the 7 optional parameters and multiple resolution modes, this is as complete as needed.

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

Parameters5/5

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

Schema coverage is 100%, but the description goes well beyond the schema by explaining each parameter's behavioral purpose: url resolution via initialInfo, property_id's internal redirect, pairing listing_id to skip resolution, and the context-saving rationale for include_description. This adds operational meaning the schema's enum/value descriptions do not convey, such as 'fastest' and 'skips resolution'.

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?

The description opens with a specific verb-resource pair — 'Fetch a property's full Redfin record' — and immediately enumerates the three possible input routes (url, property_id alone, property_id+listing_id), each with a distinct resolution path. It clearly delineates this tool from siblings like redfin_get_property_photos and redfin_get_price_history by pointing to those as alternatives for photo galleries and price history, so an agent can select it unambiguously.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance: the three call patterns are contrasted by speed ('fastest, skips resolution'), and each optional flag (include_description, include_tax_history, include_price_history) names the exact scenario that warrants it ('use this when a workflow needs both'). It also points to redfin_get_property_photos as the alternative when a photo gallery is required, making the routing decision fully explicit.

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