Skip to main content
Glama

DFX Real Estate Intelligence

by io.github.Capital-W-Holdings
OverviewDiscussionsAdmin

Who finances independent sponsor deals: ranked providers, repeat pairs, or the deals

rank_sponsor_capital
Read-onlyIdempotent

The capital parties named on announced independent sponsor transactions, aggregated. group=provider ranks lenders and equity providers by distinct deals and distinct sponsors financed, with how many sponsors they financed more than once, their roles, verticals and first and last deal. group=pair lists sponsor and provider pairs that repeat (min_deals, default 2) with the targets. group=deal returns the deal rows. role_class=debt keeps lenders, senior, mezzanine, unitranche and subordinated debt; equity keeps equity and co-invest. EBITDA filters use the TARGET's estimated EBITDA band (employees and sector ratios, confidence 0.45 to 0.55; no deal states EBITDA) and the answer says how many deals could not be sized. The answer to 'which capital providers are most active in independent sponsor deals', 'who lends to IS deals of $10M to $50M EBITDA' and 'which sponsors and lenders work together repeatedly'. DEALS LIKE ONE DEAL: give deal_sponsor and deal_company ("which lenders financed deals similar to Glen Oaks Capital's acquisition of StanChem Resins") and the deal itself is resolved, then providers on OTHER sponsors' deals in that deal's vertical since since (default 730 days ago) are ranked by distinct sponsors backed, each marked if it already backs this sponsor; the same comparable set the capital map letters use. A company that matches none of the sponsor's deals is DEAL_NOT_FOUND with the sponsor's deals listed, never a guessed sector. Returns dfx:isi: ids. 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
groupNoprovider
limitNo
sinceNoISO date; deals announced on or after.
stateNoTwo-letter state of the target company.
verticalNo
min_dealsNogroup=pair only.
role_classNoany
deal_companyNoDeals like this one: the company it bought (a name fragment is enough).
deal_sponsorNoDeals like this one: the sponsor that made it (name or dfx:isi: id).
ebitda_max_usdNo
ebitda_min_usdNo
sponsor_dfx_idNodfx:isi:<uuid> of a sponsor.
provider_dfx_idNodfx:isi:<uuid> of a capital provider.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / deal_company
      Added value: +{
+  "description": "Deals like this one: the company it bought (a name fragment is enough).",
+  "type": "string"
+}
    • addedInput schema / properties / deal_sponsor
      Added value: +{
+  "description": "Deals like this one: the sponsor that made it (name or dfx:isi: id).",
+  "type": "string"
+}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses a lot an agent would otherwise have to discover: entitlement truncation rules (first 5 rows plus locked.count/locked.by_type), permanent withholding of contact values and decision-maker names, EBITDA sizing confidence (0.45-0.55) and the fact no deal states EBITDA, DEAL_NOT_FOUND fallback behavior with no guessed sector, and the dfx:isi: return-id convention.

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 prose is dense and long, but it is front-loaded by group mode and every sentence carries a distinct rule (mode behavior, filter semantics, access limits, error handling). The trailing plans URL is the only clearly promotional, non-functional sentence.

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, output-schema-less tool with no required params, the description covers the three result shapes, the comparable-deal path, filter semantics, error mode, return identifiers, and access/entitlement behavior. An agent could invoke it correctly and interpret the locked/entitlement fields without further documentation.

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 description coverage is 54% across 13 params, and the description compensates substantially: it maps group enum values to their behaviors, explains min_deals is pair-only with default 2, defines what role_class=debt and equity include, clarifies that the EBITDA filters bind to the target's estimated band, and gives deal_sponsor/deal_company matching semantics. It leaves state, vertical, sponsor_dfx_id and provider_dfx_id to the schema, so it is not exhaustive.

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 a precise verb+resource (rank the capital parties named on announced independent sponsor deals, aggregated) and then enumerates the three output shapes (group=provider, group=pair, group=deal) plus the deals-like-one-deal variant. An agent can see exactly what this tool returns and how it differs from sibling search/get tools without opening the schema.

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?

It gives explicit when-to-use examples: 'which capital providers are most active in independent sponsor deals', 'who lends to IS deals of $10M to $50M EBITDA', and 'which sponsors and lenders work together repeatedly', and it dictates when to pass deal_sponsor/deal_company. It does not explicitly name the sibling tools to use instead (e.g. search_sponsor_capital_providers or get_sponsor_lenders), so routing is strong but not fully disambiguated.

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