Skip to main content
Glama

DFX Real Estate Intelligence

by io.github.Capital-W-Holdings

Resolve a US street address to a property or parcel

resolve_address
Read-onlyIdempotent

Turn a street address into canonical DFX object ids, with the match basis and any ambiguity stated. Returns typed objects: a 'property' (national federal programme multifamily) and/or a 'parcel' (Massachusetts assessor and registry layer). These are separate populations that barely overlap, so an address may return one, the other, or both. Free. Start here, then call get_property_record with an id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNo
limitNo
stateNoTwo letter state code
addressYesStreet address including the house number, for example '100 Binney St'

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond that: addresses may return a property, a parcel, or both, because these are 'separate populations that barely overlap,' and ambiguity is explicitly stated. This meaningfully informs the agent's expectations.

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 three focused sentences with the core action front-loaded. Each sentence earns its place, though 'Free' is a minor extra that is useful but not essential. Overall it is tight and scannable.

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

Completeness3/5

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

With no output schema, the description does a decent job explaining return categories and ambiguity, and annotations cover the safety profile. However, it omits behavior for no matches, does not clarify how limit applies, and leaves city/state usage to inference. This is adequate but has clear gaps.

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

Parameters2/5

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

Schema description coverage is only 50%, and the description does not compensate for the undocumented city and limit parameters. It restates address-level intent but adds no meaning for the optional parameters or limits. The schema covers address and state, but gaps remain for city and limit.

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 names a specific verb and resource: turning a street address into canonical DFX object ids, and specifies the output types ('property' and/or 'parcel'). This clearly distinguishes it from siblings like resolve_organization and search_parcels without requiring schema inspection.

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?

'Start here, then call get_property_record with an id' gives explicit workflow context and positions this as the entry-point lookup. It does not explicitly state when to prefer search_parcels or when not to use this tool, but the 'start here' guidance makes the intended usage 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