Skip to main content
Glama

DFX Intelligence

by io.github.Capital-W-Holdings
OverviewDiscussionsAdmin

One borrower's facilities and the lender group on each

get_borrower_facilities
Read-onlyIdempotent

Every facility a borrower group has on the BDC tape (kind, lien, principal held across lenders as a lower bound, mark on cost, pricing, PIK, maturity with its basis) with the lender group on each: every BDC holding or that held a piece, its own principal, fair value and spread, the quarters it held, and the credit manager behind it. Principal is the sum of BDC pieces: a lower bound, never the commitment, and a lender that files no schedule is invisible here. 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

NameRequiredDescriptionDefault
as_ofNogroup_by=lender: the schedule date on or before which to read (default latest).
limitNo
detailNocompact: the id, name, type, up to five key facts with their citation and counts of the related rows by type, under 2 KB. research (the default): the full answer.research
dfx_idYesA private credit graph id of the form dfx:pc:<uuid> (from search_private_credit, resolve_name or search_entities).
group_byNolender: one row per BDC with its tranches summed at one schedule date, from its own filing.facility
held_onlyNoFacilities still on a schedule at the latest quarter end.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / as_of
      Added value: +{
+  "description": "group_by=lender: the schedule date on or before which to read (default latest).",
+  "type": "string"
+}
    • addedInput schema / properties / group_by
      Added value: +{
+  "default": "facility",
+  "description": "lender: one row per BDC with its tranches summed at one schedule date, from its own filing.",
+  "enum": [
+    "facility",
+    "lender"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / limit / maximum
      Previous value: -25New value: +50
  2. Changed2 schema fields changed
    • addedInput schema / properties / detail
      Added value: +{
+  "default": "research",
+  "description": "compact: the id, name, type, up to five key facts with their citation and counts of the related rows by type, under 2 KB. research (the default): the full answer.",
+  "enum": [
+    "compact",
+    "research"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / limit / default
      Previous value: -25New value: +10
  3. Added

TDQS

A4/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: discloses that principal is a lower bound rather than a commitment, that lenders filing no schedule are invisible, and details the entitlement gating (first 5 rows, locked.count, locked.by_type, contact values withheld, every answer reporting `entitlement` and `locked`). This is unusually rich behavioral context for an agent.

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?

Purpose is front-loaded, but the opening sentence is a dense run-on parenthetical list, and the closing sentence is a promotional plan link with a URL that does not help an agent call the tool. Structure is acceptable but not lean.

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

Completeness4/5

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

With no output schema and six parameters, the description carries the burden of describing what is returned and how entitlement truncates it, which it does thoroughly. It is largely complete, though usage routing against siblings remains the missing piece.

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 83%, so the schema already documents as_of, limit, detail, dfx_id, group_by, and held_only. The description clarifies output semantics (principal as a summed lower bound, lender-group composition) but adds little param-level syntax or format beyond the schema. 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?

States a specific verb and resource — every facility a borrower group holds on the BDC tape, plus the lender group behind each — with concrete field scope (lien, principal, mark, pricing, PIK, maturity, quarters held). This is clearly distinguishable from sibling detail tools such as get_bdc_portfolio (per-BDC) or get_credit_facility (single facility).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (a by-id detail lookup) and states the prerequisite dfx_id sources, but it never says when to prefer this over get_bdc_portfolio, get_borrower_capital_structure, or get_commitments. No explicit when/when-not routing is provided, so guidance is only inferable.

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

All DFX 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