Skip to main content
Glama
chrischall

redfin-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Bulk fetch Redfin property records

redfin_bulk_get
Read-onlyIdempotent

Fetch up to 200 Redfin property records in a single call using URLs, property IDs, or ID pairs. Returns full structured data per property, with per-row error handling and a pending status for retryable rows.

Instructions

Fetch up to 200 Redfin property records in a single tool call. Provide an array of targets, each one of: a url (full Redfin homedetails URL or path with the /home/ segment), a property_id alone (resolved internally by following Redfin's /home/ redirect to the canonical listing), or a property_id+listing_id pair (fastest — skips resolution). Returns the same per-property record shape as redfin_get_property, but without a summary table — use redfin_compare_properties for that. Per-target errors are captured per-row; a single bad ID does not fail the batch. Server-side concurrency, ~6 in flight at a time, with retry-once-on-timeout per row to absorb transient bridge hiccups. The whole call is bounded by an overall hard deadline: a single slow/hung row never wedges the server — when the deadline is reached any unsettled row is returned with status: "pending" (retryable) and a pending count so you can re-run just those targets. Use this when you have a list of saved homes / candidate properties and need the full structured data for every one of them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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.
targetsYesArray of 1–200 properties to fetch
include_descriptionNoInclude each property's raw marketing/public-remarks description. Default false to save context — `extracted_features` always carries the structured signal.

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

A4.8/5.0
Behavior5/5

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

The description goes well beyond the read-only/idempotent annotations by disclosing per-target error capture, retry-once-on-timeout behavior, ~6 concurrent requests, a hard overall deadline, and the pending-status fallback for slow or hung rows. This gives the agent an accurate model of batch failure and retry semantics.

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?

The description is long but every sentence contributes behavioral or routing information, and the core purpose is front-loaded. It is dense and somewhat run-on, but not bloated or redundant.

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 complex bulk tool with no output schema, the description covers the essential runtime contract: input shapes, per-record output parity with redfin_get_property, error isolation, concurrency, timeout handling, and retry semantics. The summary-table distinction and explicit use case complete the picture.

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 100%, so the baseline is 3. The description adds meaningful semantics around the targets array by explaining the three accepted target forms, the internal resolution path for property_id, and that pairing property_id with listing_id skips resolution for speed. It does not need to repeat the schema's detailed view and include_description docs.

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 states a clear verb and resource ('Fetch up to 200 Redfin property records') and immediately differentiates itself from siblings like redfin_get_property and redfin_compare_properties by noting the same per-property record shape but no summary table. The batch aspect is explicit and unambiguous.

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 explicitly says when to use the tool: 'when you have a list of saved homes / candidate properties and need the full structured data for every one.' It also routes the agent away from the tool for summary tables by pointing to redfin_compare_properties, and implies single-record use belongs to redfin_get_property.

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