Skip to main content
Glama

DFX Intelligence

by io.github.Capital-W-Holdings
OverviewDiscussionsAdmin

How capital reaches this institution, and where it goes next

get_capital_paths
Read-onlyIdempotent

Published capital flow paths through one institution: which allocators back this manager and through which fund, which lenders finance this sponsor's borrowers and on what facilities, which properties sit under this real estate manager where a binding is validated. Each path names every hop with its graph, id, type and role, the amount where one is disclosed, the as-of date, the bases the hops rest on and a confidence. Paths are built only from identity-grade or measured links; a candidate link is labelled and carries a confidence below 0.5. NOT_COVERED means the path layer has not computed this, never that no relationship exists. 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
kindNoOne path kind as the summary names it (for example ALLOCATOR_TO_PE_FUND_TO_MANAGER).
limitNo
dfx_idYesA DFX id: dfx:fo:<uuid> (family office graph), dfx:isi:<uuid> (sponsor graph), dfx:vc:<uuid> (venture graph), dfx:pe:<uuid> (private equity graph), dfx:ria:<uuid> (registered investment adviser graph), dfx:al:<uuid> (allocator graph), dfx:pc:<uuid> (private credit graph), dfx:ref:<uuid> (real estate fund graph), or a bare real estate UUID.
include_formerNoAlso return paths through a lender edge no longer held, marked FORMER.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / include_former
      Added value: +{
+  "default": false,
+  "description": "Also return paths through a lender edge no longer held, marked FORMER.",
+  "type": "boolean"
+}
  2. Added

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses data-quality rules (paths built only from identity-grade or measured links; candidate links labelled with confidence below 0.5), the NOT_COVERED semantic, and entitlement gating (free tier returns first 5 rows plus locked.count/locked.by_type; contact values and decision-maker names withheld). It even names the response fields entitlement and locked — unusually rich behavioral context.

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 purpose is front-loaded, followed by data-quality and entitlement sections in a logical order. It is dense but organized; the closing promotional plan/URL sentence is the one part that is less about tool selection, keeping it out of the top score.

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 complex, multi-entity graph tool with no output schema, the description covers purpose, data provenance, confidence tiers, coverage semantics, and the exact form and limits of returned data. An agent has everything needed to call it and interpret the result correctly.

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 coverage is 75% (kind, dfx_id, include_former documented; limit undocumented). The description reinforces what a kind represents and gives an example kind name, but adds no syntax or format detail 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?

The opening sentence states a specific verb+resource and scope: published capital flow paths through one institution, then enumerates the three concrete path families (allocator→fund→manager, lender→borrower facility, property under a RE manager). This is far more specific than a generic sibling like relationship_path and lets an agent tell it apart 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 Guidelines3/5

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

The description scopes usage to a single institution and explains path semantics, but never names an alternative tool (e.g. relationship_path, get_borrower_capital_structure, find_capital_for_opportunity) or states when NOT to use it. Usage is implied by the resource rather than routed explicitly.

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