Skip to main content
Glama
Sign In

DFX Intelligence

by io.github.Capital-W-Holdings
OverviewDiscussionsAdmin

One BDC's schedule of investments at a quarter end

get_bdc_portfolio
Read-onlyIdempotent

Every position a BDC tagged at one quarter end (the latest unless as_of is given), each in the filer's own figures: borrower, instrument, kind, lien, principal, fair value, cost, spread, PIK, all-in rate, maturity, unfunded commitment. Debt only by default. Paged at 25. group_by=borrower gives one row per borrower, its lines summed, largest first, each line listed with its filing. 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
sortNo
as_ofNoA quarter end (YYYY-MM-DD) on the BDC's tape; default the latest.
limitNo
cursorNonext_cursor from a previous page of this tool, unchanged.
dfx_idYesA dfx:pc:<uuid> BDC id or a CIK.
group_byNoposition
include_equityNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / group_by
      Added value: +{
+  "default": "position",
+  "enum": [
+    "position",
+    "borrower"
+  ],
+  "type": "string"
+}
  2. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description goes well beyond them: page size, sort order under grouping, and a detailed entitlement model (first 5 rows plus locked counts, first 3 related names per section, contact values and decision-maker names always withheld, `entitlement`/`locked` echoed in every answer). That is exactly the non-obvious behavior an agent needs before calling.

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?

Front-loaded with what is returned and the default scope, then the entitlement constraints. The prose is dense and run-on in places (the long field list) and closes with a promotional line, but nearly every clause carries information an agent would otherwise lack.

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?

No output schema exists, so the description carries return-value burden and does so by enumerating the per-position fields, the group_by row shape, and pagination. Combined with the access-withholding model, an agent has enough to call it correctly and to interpret a partial result.

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?

With only 43% schema description coverage, the description compensates for several params: as_of semantics ('latest unless as_of is given'), include_equity ('debt only by default'), limit ('paged at 25'), and group_by with a described row shape and ordering. It does not cover sort or cursor, which the schema itself documents, so it falls short of full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: every position a BDC tagged at one quarter end, with the full field list (borrower, instrument, lien, fair value, PIK, etc.). An agent can tell this is a per-BDC holdings dump, but the description never names how it differs from near-neighbours like get_borrower_facilities or debt_maturity_schedule, so sibling differentiation is left implicit.

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?

It gives useful invocation defaults (latest quarter unless as_of, debt only unless include_equity, paged at 25, group_by=borrower for rollups), which is real usage guidance. However, it never states when to choose this over the many search_* or get_borrower_* siblings, nor any prerequisites beyond the access note.

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