Skip to main content
Glama

DFX Intelligence

by io.github.Capital-W-Holdings
OverviewDiscussionsAdmin

The commitment tape: who committed to which fund, when, in the plan's own words

search_allocator_commitments
Read-onlyIdempotent

One row per line of a plan's own disclosure: allocator, fund as printed, manager and fund resolved to the pe / vc graphs where the resolver matched, bucket, the plan's commitment amount, status (COMMITTED with the plan's closing date; DISCLOSED_HOLDING as of the report date), vintage, re-up / first-time-manager in the plan's words, the plan's own paid-in, distributed, remaining value, IRR and multiple where printed, and the source URL with a quote. Filter by allocator, manager (who backs this manager), fund, consultant, status, bucket, re-ups only, first-time only, since and until dates; sort by date, amount or vintage. A target is never an actual, a disclosed holding is never an approval, commitment dollars repeat across reports, re-ups are the plan's own words, estimates are labelled and nothing predictive is published. 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
limitNo
queryNoAllocator, fund or manager name contains.
sinceNoISO date; commitment or approval date on or after (a holding with neither: its vintage year, never the report date).
untilNoISO date; the same decision date on or before. since and until together give one year: 2018-01-01 to 2018-12-31.
bucketNo
cursorNonext_cursor from a previous page of this tool, unchanged.
statusNo
fund_dfx_idNoAn allocator graph id of the form dfx:al:<uuid> (from search_allocators, resolve_name or search_entities).
re_ups_onlyNo
manager_dfx_idNoAn allocator graph id of the form dfx:al:<uuid> (from search_allocators, resolve_name or search_entities).
first_time_onlyNo
allocator_dfx_idNoAn allocator graph id of the form dfx:al:<uuid> (from search_allocators, resolve_name or search_entities).
consultant_dfx_idNoAn allocator graph id of the form dfx:al:<uuid> (from search_allocators, resolve_name or search_entities).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / until
      Added value: +{
+  "description": "ISO date; the same decision date on or before. since and until together give one year: 2018-01-01 to 2018-12-31.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / since / description
      Previous value: -"ISO date; effective date on or after."New value: +"ISO date; commitment or approval date on or after (a holding with neither: its vintage year, never the report date)."
  3. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Fund or manager name contains."New value: +"Allocator, fund or manager name contains."
  4. Added

TDQS

A3.9/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it defines status semantics (COMMITTED carries the plan's closing date; DISCLOSED_HOLDING is as of the report date), warns that commitment dollars repeat across reports, that re-ups are the plan's own words, and that estimates are labelled with nothing predictive published. The access block spells out exactly how results degrade for non-entitled callers (first 5 rows in full plus locked.count/locked.by_type, contact values reduced to types and counts) and how that is surfaced 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?

Front-loaded correctly with the row concept, but the content is delivered as one very long run-on sentence followed by a dense access/paywall paragraph and a marketing URL. Nearly every clause carries information, yet the wall-of-text form makes it hard to scan and the sales CTA could be trimmed.

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?

For a 14-parameter search tool with no output schema, the description does the heavy lifting: it describes the returned row shape, the entitlement-degraded shape, and the semantic caveats an agent needs to avoid misreporting. Pagination (cursor/next_cursor) and limit are left entirely to the schema, which is a minor gap rather than a blocker.

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 57% schema coverage across 14 parameters, the description earns credit by mapping filters to meaning, notably 'manager (who backs this manager)' which disambiguates the manager_dfx_id filter from allocator_dfx_id, and by glossing status and re-up/first-time semantics. It does not cover limit/pagination behavior or sort direction, both of which remain schema-only.

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 resource with unusual precision: 'one row per line of a plan's own disclosure' followed by an enumeration of the exact columns returned (allocator, fund as printed, resolved manager, bucket, commitment, status, vintage, paid-in, IRR, source URL with quote). An agent knows immediately this is the allocator/LP commitment tape rather than the VC fund or deal tape. It stops short of naming the adjacent siblings it could be confused with (get_commitments, search_vc_lp_commitments), so it does not fully clear the bar for 5.

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 filter and sort enumeration implies when the tool is useful ('filter by allocator, manager (who backs this manager), fund, consultant, status, bucket, re-ups only, first-time only, since and until dates'), which is decent implied usage guidance. However, there is no statement of when to prefer this over search_vc_lp_commitments, search_allocators or get_commitments, and no exclusions or prerequisites beyond the paywall 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