Skip to main content
Glama

Homesage.ai MCP

Get Sold Properties by ZIP

get_sold_properties_by_zip
Read-only

What it returns

Every residential property sold in a given US ZIP code within the last 365 days, with sale date, sale price, coordinates, and basic property characteristics (bed/bath, square footage, year built, lot size). Sourced from the residential_sold collection — a deduplicated rollup of MLS sold records refreshed on demand when the per-ZIP cache is older than 4 hours.

When to use it

  • Build a "recent sales in my neighborhood" widget on a property page.

  • Estimate market velocity for a ZIP code (sales per month, median DOM).

  • Seed a comps analysis without specifying individual subject properties.

  • Sanity-check listing prices against actual sale prices.

Date range

By default the endpoint returns the full trailing 365 days. Pass start_date, end_date, or both (YYYY-MM-DD) to narrow that to a specific window — for example one calendar month at a time instead of re-pulling the whole year on every poll:

?zip=95630&start_date=2026-08-01&end_date=2026-08-31

Both bounds are optional and inclusive, and both are independent: pass only start_date for an open-ended window, or only end_date to cut off recent sales. Passing neither leaves existing behaviour unchanged.

Either bound must fall within the last 365 days. An older date returns 400 naming the earliest date we can serve, rather than quietly returning a partial set.

Property type

Pass property_type to keep only the types you model. One value or a comma-separated list, matched against the same property_type field each row returns:

?zip=95630&property_type=single_family
?zip=95630&property_type=single_family,townhomes&start_date=2026-08-01&end_date=2026-08-31

Omitting it returns every type, exactly as before. An unknown value returns 400 listing the accepted values rather than an empty result.

Pricing

1 credit per 20 properties returned, rounded up. A request that returns 100 properties costs 5 credits. Use the limit parameter to cap the cost — a limit=20 always costs exactly 1 credit. Charged only on 200; 402/400/5xx cost nothing.

Errors

Status

Meaning

400

Missing zip parameter, non-integer limit, a malformed / out-of-window start_date or end_date, or an unknown property_type.

401

Authentication failed or account missing.

402

No subscription, or insufficient credits for the property count this ZIP would return. The error body includes the credit estimate so you can lower limit and retry.

503

Upstream datastore or refresh error. Safe to retry.

FAQ

How fresh is the data?

The per-ZIP cache refreshes when stale (older than 4 hours) on demand. A first request to a cold ZIP may take longer while the refresh runs; subsequent requests within the 4-hour window hit cache.

Why do some properties have sold_price: null?

The MLS suppresses price on private sales, off-market transfers, and some agent-sale records. The property still appears (it sold), but the price field is null. Filter on your side if you need price-bearing records only.

What counts as "residential"?

Everything the sold feed files as residential: single-family, condos, townhomes, multi-family, apartments, mobile homes, plus a small tail of other types. Each row's property_type says which, and the property_type filter takes the same values. Commercial and land-only records are rare here — they live in other collections.

Why is dom sometimes null?

Days-on-market requires listing-history dates that older records may not carry. For records that lack dom natively, we compute it best-effort from list_date to sold_date; when neither path resolves, the field is null.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "zip": "<zip>"
    },
    "name": "get_sold_properties_by_zip"
  }
}

Input Schema

NameRequiredDescriptionDefault
zipYes5-digit US ZIP code. Example: `95630`.
limitNoCap the result count. When set, the response is the most recent N sales (after dedup + recency filter). Used to control credit cost — `limit=20` always costs 1 credit. Omit for the full last-365-days list.
end_dateNoLatest sale date to include, as `YYYY-MM-DD`. Optional — omit for no upper bound. Inclusive: a sale on this exact date is returned. Must be on or after `start_date` and within the last 365 days.
start_dateNoEarliest sale date to include, as `YYYY-MM-DD`. Optional — omit for the full 365-day window. Inclusive: a sale on this exact date is returned. Must fall within the last 365 days; anything older returns `400`, since that is the whole window we retain.
property_typeNoKeep only these property types. One value or a comma-separated list, e.g. `single_family` or `single_family,townhomes`. Optional — omit for every type. Values are the ones the response's `property_type` field carries, chiefly `single_family`, `condos`, `townhomes`, `multi_family`, `apartment`, `mobile`, `duplex_triplex`, `coop`, `condo`, `land`, `farm`, `other`. Case-insensitive; `-` and spaces are read as `_`. An unknown value returns `400` listing the full accepted set.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations it discloses the 4-hour per-ZIP cache refresh and the cold-start latency, a precise credit model (1 credit per 20 rows, charged only on 200, free on 402/400/5xx), a full status-code table with retryability for 503, and the null-sold_price / null-dom edge cases. This is exactly the operational context an agent cannot get from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Headers and the front-loaded 'What it returns' / 'When to use it' ordering are good, but the description runs long for a 5-parameter read and repeats itself: the 365-day window, the property_type value list, and the cache freshness are each stated two or three times across the body and the FAQ. Several FAQ entries duplicate what the parameter schema already documents.

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?

Even though an output schema exists, the description covers cost, freshness, failure modes, and data-quality caveats (null price, null dom, what counts as residential), so an agent can invoke this correctly and interpret results without further lookups. Nothing material for correct invocation is missing.

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 already 100%, but the description still adds meaning: that limit returns the most recent N after dedup, that start_date and end_date are independent and inclusive, and that out-of-window dates fail loudly with a 400 naming the earliest servable date rather than silently truncating. Much of the property_type value list and date formatting repeats the schema, so it is additive but overlapping rather than wholly new.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line states a specific resource and scope: 'Every residential property sold in a given US ZIP code within the last 365 days, with sale date, sale price, coordinates, and basic property characteristics.' It indirectly separates itself from get_comps ('seed a comps analysis without specifying individual subject properties') but never names get_sold_count_by_zip or get_comps outright, so sibling routing is left partly implicit.

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?

The 'When to use it' block gives four concrete scenarios, and the date-range and property_type sections explain legitimate usage patterns (narrow by month instead of re-pulling the year). It stops short of explicit 'when not to use / use X instead' guidance against the many sibling tools such as get_sold_count_by_zip.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources