Skip to main content
Glama
Capital-W-Holdings

DFX Real Estate Intelligence

Find dated property events by type, state and time window

search_property_events
Read-onlyIdempotent

Search dated property events across US, including compliance period endings, subsidy expiries, loan maturities, distress flags, permits, and sales. Filter by event type, state, and time window to find upcoming or past occurrences.

Instructions

Dated events over US properties and parcels, with provenance and a headline you can show a person. Covers LIHTC compliance period endings (the Year 15 recapitalisation trigger, 11,956 of them), HUD subsidy contract expiries (4,721), scheduled loan maturities (3,422) now national rather than Massachusetts, CMBS distress and workout reporting (167 delinquency flags across 26 states, 128 foreclosures across 22), issued building permits and demolition filings (Boston only), and recorded sales (43,680, 2 states). 8,194 events fall inside the next 548 days, measured 2026-09-09. Filter by event type, state and days ahead. An unrecognised event type is REFUSED with the served vocabulary, never answered with an empty list. Free. PAGING: a full page carries next_cursor. Pass it back as cursor with every other argument unchanged to continue; next_cursor is null on the last page, and that is the only signal the traversal has ended. The counts above are therefore all reachable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax 50. Results are ordered by occurred_at ASCENDING. For the expiry families (maturities, compliance periods, subsidy contracts, leases) a call with no `within_days` now returns events dated TODAY OR LATER, soonest first; the envelope reports this as `applied_date_floor`. Pass `include_past=true` for the full history.
stateNoTwo letter state code
cursorNoContinue a previous page. Pass the `next_cursor` returned by the last call, with EVERY other argument identical, to get the rows after it. Repeat until `next_cursor` is null, which is the only signal that the whole result set has been read: a short page is not the end, because a page can shrink when two sources publish the same event. Opaque; do not construct or edit one. An unreadable cursor is REFUSED rather than ignored, so a caller can never be silently restarted at page one.
event_typeNoONE family per call. Omit it and every family is searched together, which mixes populations of very different sizes and is rarely what you want: name the family. The list is generated from what this server actually publishes today, so it grows without a release. Call dfx_coverage for how many of each family exist in a given state before reading an empty result as an absent market.
within_daysNoFORWARD ONLY: it filters to events occurring between today and N days from now, and it cannot reach the past. For a backward-looking question ("recent sales", "foreclosures that already happened") OMIT this argument entirely. A historical event fails every forward window, so passing one returns an empty list that reads like an absent market. 548 is eighteen months. FORWARD FAMILIES, which this argument is for: COMPLIANCE_PERIOD_ENDING, LEASE_EXPIRING, LOAN_MATURITY_SCHEDULED, SUBSIDY_CONTRACT_EXPIRING. ENTIRELY HISTORICAL as of 2026-09-09, where ANY value returns nothing: BANKRUPTCY_EVENT, CERTIFICATE_OF_OCCUPANCY, DEMOLITION_FILED, DISTRESS_FLAG_RAISED, FORECLOSURE_EVENT, LOAN_MODIFIED, PERMIT_ISSUED, PROPERTY_SOLD, USE_CONVERSION_PERMITTED.
include_pastNoReturn the whole tape including events already past, instead of the default forward window applied to expiry families. Has no effect when `within_days` is given, which sets its own window, and none on historical families, which are never floored.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the read-only and idempotent hints, the description discloses concrete behavior: ordering by occurred_at ascending, default date flooring for expiry families, refusal of unreadable cursors and unrecognized event types, and that short pages do not indicate the end of results. It also explains the envelope's applied_date_floor and the effect of include_past, providing full 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 long and dense, but almost every sentence carries essential caveats. It is well-structured with clear sections for families, filtering, paging, and forward-only behavior. However, some repetition exists (e.g., the statement that next_cursor null is the only signal of completion appears twice in slightly different forms), making it slightly less concise than ideal.

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 number of parameters (6) and the absence of an output schema, the description is remarkably complete. It explains paging, forward/backward temporal semantics, the distinction between expiry and historical families, and the envelope field applied_date_floor. It also addresses edge cases like empty results and cursor refusal, ensuring a caller has all needed context to use the tool correctly.

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?

While the schema already describes each parameter, the description adds crucial semantic depth: within_days is strictly forward-only and cannot reach the past, include_past has no effect when within_days is given, and the event_type enum is generated from what the server actually publishes. It also clarifies the interplay between parameters and the meaning of cursor opacity.

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 clearly states the tool provides dated events over US properties and parcels with provenance and a headline, and enumerates the event families covered. It distinguishes itself from siblings by its specific focus on event timelines and filtering, leaving no ambiguity about its role.

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?

The description gives explicit guidance on when and how to use the tool: it advises naming one event family to avoid mixing populations, explains forward-only windows and historical families, recommends calling dfx_coverage before interpreting empty results, and details paging behavior with cursor usage. It also clarifies when to omit within_days for backward-looking questions.

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