Skip to main content
Glama
Capital-W-Holdings

DFX Real Estate Intelligence

What DFX has learned since your last call

changes_since
Read-onlyIdempotent

Poll for newly learned real estate events and data since a cursor. Use with pagination to retrieve changes, filterable by event type, state, or property.

Instructions

Poll for what is NEW to you, ordered by when DFX learned it rather than by when it happened. TWO CALLS ARE REQUIRED BEFORE YOU SEE ANYTHING: the first, with no cursor, deliberately returns ZERO events and a starting position; the second, with that cursor, returns what DFX learned in between. If you want rows now rather than a subscription, call search_property_events instead. Filter by event type, state, or a specific property or parcel id. Deterministic and indexed, so it is cheap to call often. Free. HISTORICAL FAMILIES DO FLOW THROUGH HERE. within_days on search_property_events cannot reach the past, but this tool is ordered by when DFX LEARNED a fact, not when the fact happened, so a foreclosure that occurred months ago and was ingested today arrives in today's delta. A distress or sales feed built on this works.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax 50. A full page sets `complete: false` in the envelope, which means the backlog was longer than one call: go again immediately with the returned cursor rather than waiting for your next poll interval. The cursor is the last row on the page, never the present moment, so nothing is skipped by doing so.
sinceNoOpaque cursor from a previous call. Omit on the first call to establish a position; that call returns no events by design.
stateNoTwo letter state code
event_typeNoOne family. Same vocabulary as search_property_events.
place_dfx_idNoWatch one property or parcel

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 readOnly/idempotent/non-destructive annotations, the description discloses key behavioral traits: the ordering by 'when DFX LEARNED a fact' vs. when it happened, the deterministic and indexed nature ('cheap to call often'), the first-call returning zero events by design, and the cursor semantics with the 'complete: false' envelope. It also states that it is 'Free' and explains the historical-family flow explicitly. This goes well beyond the annotations and fully informs an agent of the tool's runtime behavior.

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

Conciseness5/5

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

The description is dense but well-organized: the first paragraph delivers the core purpose, protocol, alternative, filters, and performance characteristics; the second paragraph addresses the important historical-family edge case. Every sentence carries needed information without fluff. The use of capitalization and explicit warnings (e.g., 'TWO CALLS ARE REQUIRED') make critical points stand out despite the length.

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 polling/cursor-based nature and the absence of an output schema, the description is remarkably complete. It explains the two-call flow, the cursor's meaning, the envelope's 'complete: false' flag, the filtering options (event_type, state, place_dfx_id), the relationship to search_property_events, and the historical-family coverage. It even clarifies that the event_type vocabulary matches search_property_events. This provides all necessary context for correct invocation and interpretation of responses.

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 has detailed descriptions for all 5 parameters (100% coverage), so the baseline is 3. The description adds extra meaning by explaining the two-call protocol in plain language and clarifying the limit parameter's effect on the envelope and cursor handling ('A full page sets complete: false... go again immediately with the returned cursor'). This supplements the schema descriptions meaningfully, justifying a 4.

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 states the tool's purpose with precision: 'Poll for what is NEW to you, ordered by when DFX learned it rather than by when it happened.' It also clearly distinguishes it from the sibling tool search_property_events by noting the alternative for immediate rows. The first paragraph explicitly establishes the core behavior and the two-call protocol, leaving no ambiguity about what the tool does.

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 direct usage guidance by specifying when to use this tool versus the alternative: 'If you want rows now rather than a subscription, call search_property_events instead.' It also explains the required two-call sequence ('TWO CALLS ARE REQUIRED BEFORE YOU SEE ANYTHING') and highlights the historical-family advantage: 'within_days on search_property_events cannot reach the past... a foreclosure that occurred months ago and was ingested today arrives in today's delta.' This is explicit, actionable guidance for an agent deciding between tools.

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