Skip to main content
Glama
chrischall

redfin-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get Redfin climate risk for a property

redfin_get_climate_risk
Read-onlyIdempotent

Retrieve First Street Foundation climate risk scores—flood, fire, heat—for a Redfin property using its homedetails URL.

Instructions

First Street Foundation climate risk scores for a property. COVERS: flood (factor 1–10, FEMA zones, 30-year annual chance series), fire (factor 1–10, relative risk, insurance price band, provider count), heat (factor 1–10, cumulative-risk projections at 0/5/10/15/20-year horizons). DOES NOT COVER: landslide. This is the Helene-relevant risk vector in the NC mountains market and many parts of California / the Pacific Northwest. First Street has no landslide product — for that vector check the NC Geological Survey landslide hazard maps (NC-specific) or USGS landslide hazard data (national). Surfaced on every response as not_covered: ['landslide']. Response shape: when First Street data is available, available: true with the risk blocks; when not, { available: false, reason } where reason is one of no_first_street_data, new_construction, address_outside_coverage. Sourced from Redfin's server-rendered homedetails HTML (no clean stingray endpoint exists). Pass a homedetails URL (full or path) — it must end in a /home/<propertyId> segment; any other page is rejected without being fetched. When a cluster_id is surfaced, properties with the same value typically share identical climate scores — use that to group N properties and skip redundant fetches.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesRedfin homedetails URL or path (e.g. /NY/Brooklyn/42-Monroe-St-11238/home/40732555)

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. First observedv0.10.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, open-world, but the description adds substantial behavior beyond them: the data source (server-rendered homedetails HTML, no clean endpoint), URL validation that rejects non-/home/<id> pages without fetching, the surfaced not_covered field, and the available:true/false response branches with enumerated reason values (no_first_street_data, new_construction, address_outside_coverage).

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?

Well front-loaded with the core purpose, and the COVERS/DOES NOT COVER and 'Response shape' labels make it scannable. It is dense and the NCGS/USGS landslide detour plus cluster_id note push length for a one-parameter tool, though both still serve routing/dedup decisions.

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 carries the full burden and does so: it documents the response shape, success and failure branches with reason enums, the not_covered field, and the sourcing. An agent has everything needed to call it and interpret the result.

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% (baseline 3), and the description adds real value beyond the schema's example: the URL must end in a /home/<propertyId> segment, accepts full or path form, and other pages are rejected without being fetched. That constraint meaningfully clarifies how to construct the single parameter.

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?

Names a specific verb+resource ('First Street Foundation climate risk scores for a property') and then enumerates exactly which vectors are returned (flood, fire, heat) with their scoring scales. The COVERS/DOES NOT COVER framing makes the scope of the tool unambiguous, including the explicit landslide exclusion.

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?

Gives clear applicability context (property-level, Helene-relevant NC mountains/California/Pacific Northwest markets) and practical dedup guidance via cluster_id. It does not, however, explicitly route the agent to the natural alternatives redfin_get_climate_risk_bulk or redfin_get_area_climate_baseline, so the when-to-use-vs-sibling condition is left to inference.

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