Skip to main content
Glama

DFX Real Estate Intelligence

by io.github.Capital-W-Holdings
OverviewDiscussionsAdmin

CMBS loans with status, special servicing, DSCR, maturity and sponsor

search_cmbs_loans
Read-onlyIdempotent

Loans on the ACTIVE CMBS tape (SEC ABS-EE, each loan's latest monthly reading, read within 100 days of the newest period) with the servicer's own fields: payment status (current, 30/60/90 days, non performing matured balloon), special servicer and transfer date, whether it is in special servicing now, workout strategy, modification, current DSCR with its basis, occupancy, appraisal and LTV, balance, maturity, originator, and the sponsor as the prospectus annex discloses it (sponsor column, else carve-out guarantor, labelled). Each row carries the core property id where the building chain resolved it, for get_property_record. Filter by state, property type, maturity window, distress or sponsor text, or ask for ONE building with property (its name or street address, e.g. 'Park West Village', '1384 Broadway') or property_dfx_id (the id resolve_address or get_property_record gave). The answer to 'Texas multifamily loans maturing in 18 months that are in special servicing, and who sponsors them'. Conduit CMBS only: bank balance sheet, agency and debt fund loans are not on this tape. ACCESS: without a paid DFX plan on the vertical, a list returns its first 5 rows in full and a count of the rest by type (locked.count, locked.by_type), never the rows; a record names its subject and the first 3 related names per section; contact values (email, phone, profile URLs) and decision-maker names are never returned, only their types and counts. Every answer says what it withheld in entitlement and locked. Full access: DFX Intelligence, 7 days free at https://dfxintel.com/data-factory/plans.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
stateNoTwo-letter state of the property.
cursorNonext_cursor from a previous page of this tool, unchanged.
sponsorNoSponsor or guarantor name contains, as the annex prints it.
distressNospecial_servicing: transferred and not returned; not_current: any payment status other than current; any: either.
dscr_maxNoOnly loans whose latest DSCR is strictly below this (the current filing, else the last DSCR reported within 12 months; each row prints the period it was reported for). 'DSCR under 1.2' is dscr_max 1.2.
propertyNoOne building by its name or street address, as a buyer writes it: 'Renaissance Seattle Hotel', '225 & 233 Park Avenue South', 'One West 34th Street'. Matched on the tape's property name and address after normalising both (case, punctuation, & as and, Street as St); a single house number also finds a range address. Use this, not sponsor, for a building name.
loan_keysNoSpecific loan keys (deal CIK:asset number) from a previous answer.
maturity_toNoISO date.
maturity_fromNoISO date.
property_typeNo
property_dfx_idNoA core property id (from resolve_address or get_property_record): the loans on that building, including its notes in other trusts.
maturity_within_daysNoLoans maturing from today to today plus this many days.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / property
      Added value: +{
+  "description": "One building by its name or street address, as a buyer writes it: 'Renaissance Seattle Hotel', '225 & 233 Park Avenue South', 'One West 34th Street'. Matched on the tape's property name and address after normalising both (case, punctuation, & as and, Street as St); a single house number also finds a range address. Use this, not sponsor, for a building name.",
+  "type": "string"
+}
    • addedInput schema / properties / property_dfx_id
      Added value: +{
+  "description": "A core property id (from resolve_address or get_property_record): the loans on that building, including its notes in other trusts.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / dscr_max
      Added value: +{
+  "description": "Only loans whose latest DSCR is strictly below this (the current filing, else the last DSCR reported within 12 months; each row prints the period it was reported for). 'DSCR under 1.2' is dscr_max 1.2.",
+  "maximum": 10,
+  "minimum": 0,
+  "type": "number"
+}
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial behavior: the entitlement model (first 5 rows plus locked.count/locked.by_type without a paid plan), what is never returned (contact values, decision-maker names), and the fact that every answer reports withheld data in `entitlement` and `locked`.

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

Conciseness3/5

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

Information-dense and front-loaded with the returned fields, but it is delivered as one long run-on paragraph where the access/entitlement rules and the conduit-scope caveat are buried mid-block. Splitting into returned-fields / filtering / access sections would improve scanability.

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?

For a 13-parameter tool with no output schema, the description covers what is returned, the filtering surface, the tape boundary, and the access/entitlement behavior. An agent has everything needed to call it correctly and interpret a partial response.

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?

Schema coverage is high (85%), so the baseline is 3, but the description adds real semantics beyond the schema: dscr_max means strictly below the latest filing (else last DSCR within 12 months), property matching normalizes case/punctuation/&/Street, and property vs sponsor is disambiguated for building names.

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?

States a specific verb+resource (loans on the ACTIVE CMBS tape) and enumerates the exact fields returned (payment status, special servicing, DSCR, occupancy, LTV, sponsor). It explicitly distinguishes itself from siblings by scope: 'Conduit CMBS only: bank balance sheet, agency and debt fund loans are not on this tape,' separating it from search_re_fund_loans and search_bank_cre_exposure.

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?

Gives concrete when-to-use conditions and a worked example ('Texas multifamily loans maturing in 18 months that are in special servicing, and who sponsors them'). It routes between filters explicitly — 'Use this, not sponsor, for a building name' — and names the upstream tools (resolve_address, get_property_record) that produce property_dfx_id.

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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources