Skip to main content
Glama

DFX Real Estate Intelligence

by io.github.Capital-W-Holdings

PAID, $1.00: confirmed commercial mortgage maturities for one state

debt_maturity_schedule
Read-onlyIdempotent

PAID: $1.00 USD per delivered schedule. This is the ONLY priced tool on this server. The other eight are free, keyless and permanently so. Returns the LOAN rather than the event: for one US state and one forward window, up to 200 loans with maturity date, original principal, lender name, instrument type, origination date and the secured property's address, deduplicated to one row per loan and ordered by maturity. Every maturity_basis is 'confirmed': 19,881 of 19,881 loans carry a date filed with the SEC by a servicer or recorded by HUD, and none is estimated or inferred from a term length. HOW TO GET A PRICE, FREE: call this tool with no authorize argument and no credential. You are not charged and not refused. You receive a real quote for your exact arguments, the price, every field that would arrive, the known limits, and the number of rows your dollar would actually buy, so a filter that would deliver one row is visible before you spend anything. HOW TO ACTUALLY BE CHARGED: resend the identical call with authorize and an X-DFX-Account header holding a funded account key. THIS IS THE ONLY THING ON THIS SERVER THAT NEEDS A CREDENTIAL, and it is the reason the handshake's 'no signup' is about the free tier and not about this tool. To get one, call open_dfx_account on this same server; no human step is needed to open it, and a balance must be funded before it can spend. Everything else here, including the quote itself, needs no account at all. FREE ALTERNATIVE, AND IT IS A REAL ONE: search_property_events with event_type=LOAN_MATURITY_SCHEDULED returns up to 50 maturity EVENTS for the same state, dated and sourced, with no principal, no lender and no instrument. It is also a smaller population: an event has to be resolved to a single building, so a loan secured by several is in the paid tape and not in the free index. Use the free tool for timing, this one for a refinancing conversation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum loans, up to 200. The price does not change with the row count.
stateYesTwo letter state code. Required: the schedule is priced per state.
authorizeNoOmit to be quoted. Supply to be charged and served in one response.
within_daysNoForward window from today. Default 548, eighteen months.

TDQS

A4.6/5.0
Behavior5/5

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

Indepedently of the annotations, the description discloses the paid nature, credential requirement, quote-first flow, exact charging trigger, data provenance ('19,881 of 19,881 loans carry a date filed with the SEC...'), deduplication and ordering behavior, and row limits. This is rich behavioral context beyond what readOnlyHint/idempotentHint/destructiveHint already provide, and nothing contradicts the annotations.

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 but well structured with labeled paragraphs and front-loaded purpose. Some redundancy exists, such as repeating that this is the only priced tool and the only credential-needing operation, but the complexity of a paid tool with a quote/charge handshake justifies most of 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?

Despite having no output schema, the description enumerates the returned fields, row cap, ordering, deduplication, data source, pricing behavior, credential requirements, and the free alternative. An agent has everything needed to decide whether and how to invoke the tool, including how to avoid being charged accidentally.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema already documents state, limit, within_days, and authorize with defaults and pricing notes. The description mostly restates this information at a higher level rather than adding new parameter-level semantics. It reinforces the authorize without/with flow, but that meaning is already present in the schema, so baseline 3 is appropriate.

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 precise statement of what the tool delivers: priced, confirmed commercial mortgage maturity schedules for one state and one forward window, returning loan records rather than events. It names the specific fields returned and explicitly distinguishes itself from the sibling search_property_events, making the tool's identity unmistakable.

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, actionable usage guidance: omit authorize for a free quote, resend with authorize and an X-DFX-Account header to be charged, and use search_property_events as the free alternative when only timing is needed. It even closes with a directional rule: use the free tool for timing, this one for a refinancing conversation.

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