Skip to main content
Glama

DFX Real Estate Intelligence

by io.github.Capital-W-Holdings

Find dated property events by type, state and time window

search_property_events
Read-onlyIdempotent

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, 13,549 of them), HUD subsidy contract expiries (4,721), scheduled loan maturities (3,717) now national rather than Massachusetts, CMBS distress and workout reporting (188 delinquency flags across 26 states, 142 foreclosures across 22), issued building permits and demolition filings (Boston only), and recorded sales (43,857, 2 states). 8,631 events fall inside the next 548 days, measured 2026-09-01. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax 50. Results are ordered by occurred_at ascending, soonest first, so a small limit gives you the nearest events rather than an arbitrary sample.
stateNoTwo letter state code
event_typeNo
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-01, where ANY value returns nothing: BANKRUPTCY_EVENT, CERTIFICATE_OF_OCCUPANCY, COMPANY_CONTRACTED, DEMOLITION_FILED, DISTRESS_FLAG_RAISED, FORECLOSURE_EVENT, LEASE_TERM_REVISED, LOAN_MODIFIED, PERMIT_ISSUED, PROPERTY_SOLD, USE_CONVERSION_PERMITTED.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already establish that the tool is read-only, idempotent, and non-destructive, so the description adds useful behavioral detail beyond those: unrecognized event types are refused with the served vocabulary rather than returning an empty list, and the within_days semantics separate forward-looking from historical events. It also discloses coverage boundaries such as Boston-only permits and two-state sales data.

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 first sentence is a strong front-loaded summary, and the subsequent coverage counts and scope notes earn their place by setting precise expectations. The description is dense and slightly hard to scan due to parenthetical statistics, but it contains no filler or redundant restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the absence of an output schema, and the presence of 4 parameters, the description supplies the most important operational context: what data is included, what filters exist, how time windows behave, and how invalid event types are handled. It is not a 5 only because it never describes the result envelope beyond mentioning provenance and a headline.

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?

The schema already documents limit, state, and within_days well, with 75% parameter description coverage. The tool description adds value by grouping event types into forward vs. historical families and by explaining the refusal behavior for unrecognized event types, which helps an agent combine event_type and within_days correctly.

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 opens with a specific verb and resource: 'Dated events over US properties and parcels,' then enumerates concrete event families with counts and geographic boundaries. This gives an agent a clear, distinctive picture of what the tool returns, and it is easy to tell apart from siblings like search_parcels or get_property_record.

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 description provides strong context for when to use it by listing the covered event types, the geographic scope, and the intended filters (event type, state, days ahead). It stops short of explicitly stating when not to use it or naming an alternative sibling, but the coverage detail makes the intended use case clear.

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

All DFX Real Estate Intelligence toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool targets a clearly distinct task: exact address resolution versus filter-based parcel search, subscription delta versus event search, coverage status versus natural-language routing, and the account lifecycle is split into open/fund/status. Even the closest pairs, changes_since and search_property_events, are explicitly disambiguated in their descriptions.

Naming Consistency3/5

The dominant pattern is verb_noun, e.g. resolve_address, search_parcels, get_property_record, but several tools break it: dfx_coverage, dfx_payment_status, debt_maturity_schedule, changes_since, and what_can_dfx_answer. These names are still readable and semantically clear, so the naming is mixed rather than chaotic.

Tool Count5/5

Twelve tools is well within the ideal range and each tool earns its place: discovery, coverage, resolution, search, records, event subscription, paid maturity schedules, and the account/payment lifecycle all have a distinct role. No tool feels redundant or ornamental.

Completeness4/5

The read-only real estate intelligence surface is well covered: coverage checks, address and organization resolution, property records, parcel search, event search, delta subscription, paid loan schedules, and account funding. The main gap is that resolve_organization returns entity IDs without an obvious downstream tool for organization detail, and there is no separate event detail endpoint, but agents can work around these.

Resources