Skip to main content
Glama
chrischall

redfin-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Compare multiple Redfin properties side-by-side

redfin_compare_properties
Read-onlyIdempotent

Compare 2–25 Redfin properties side-by-side to evaluate price, beds, baths, sqft, and more. Get per-property records with derived price-drop and optional summary table.

Instructions

Fetch and compare 2 to 25 Redfin properties side-by-side. Provide an array of targets, each either a url or a property_id+listing_id pair. Returns the full per-property record (price, beds/baths, sqft, year built, HOA monthly, last sold, derived price-drop, etc.). For >25 properties or workflows that don't need side-by-side analysis use redfin_bulk_get. Pass include_summary: true for an aligned-by-field summary table (default false to save context — the per-row records carry the same data, so emitting both duplicates ~30% of the response weight). Each record's extracted_features (lake_front, hot_tub, basement, furnished, dock, community) is always included. The raw marketing description is omitted by default — opt in with include_description: true. Errors for individual properties are captured per-row with a status (ok / timeout / bridge_down / protocol / pending / other) and retryable. Server-side concurrency (~6 in flight) with retry-once-on-timeout per row; the whole call is bounded by an overall deadline, and any row still unsettled then comes back as status: "pending" (retryable) with a pending count.

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 2–25 properties to compare. Use `redfin_bulk_get` for larger batches that don't need side-by-side analysis.
include_summaryNoInclude the aligned-by-field `summary` table. Default false — the per-row records carry the same data, so emitting both duplicates ~30% of the response weight. (#37)
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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds substantial behavioral context beyond that: per-row error statuses (ok/timeout/bridge_down/protocol/pending/other), retryability, server-side concurrency, overall deadline, and the pending fallback. It also discloses response-size tradeoffs (summary duplication) and default omissions. This is exemplary transparency.

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 longer than minimal, but every sentence carries operational information: purpose, target forms, response fields, sibling routing, parameter trade-offs, error handling, and concurrency behavior. It is dense and front-loaded, though it could be tightened with structural formatting. Appropriate for the tool's complexity.

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?

Given the tool's complexity (4 params, varied target forms, per-row error handling, no output schema), the description covers everything an agent needs: accepted inputs, response contents, error semantics, scaling behavior, and alternatives. There are no obvious gaps that would cause incorrect invocation.

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 description coverage is 100%, so the baseline is 3. The description adds genuine semantic value by clarifying that each target is either a url or a property_id+listing_id pair, and by noting that extracted_features is always included regardless of other parameters. This goes beyond the schema's field-level descriptions.

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 begins with a specific verb-resource-scope statement ('Fetch and compare 2 to 25 Redfin properties side-by-side') that clearly distinguishes it from redfin_bulk_get and other Redfin tools. It conveys the exact operation and constraints without ambiguity.

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?

Explicitly states when NOT to use the tool ('For >25 properties or workflows that don't need side-by-side analysis use redfin_bulk_get') and gives parameter-level usage advice (include_summary default false to save context, include_description opt-in). This leaves no doubt about selection criteria.

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