Skip to main content
Glama

DFX Intelligence

by io.github.Capital-W-Holdings
OverviewDiscussionsAdmin

Check a claim against DFX's evidence

verify
Read-onlyIdempotent

SUPPORTED, PARTIALLY_SUPPORTED, CONTRADICTED or UNKNOWN for a claim, with the observations. Give a sentence ('Family Office X invested in Company Y in 2025', 'Z is a business development company', 'A is the investment adviser of BDC B', 'Pension P committed to Fund F') or a structured subject / predicate / object / year. SUPPORTED always carries at least one evidence row with a citation; a name resolves only to a record carrying that name, otherwise the answer is UNKNOWN with candidates. DFX contradicts only what its own record contradicts; absence of evidence is UNKNOWN, never CONTRADICTED. Its predicates cover investment, acquisition, adviser, commitment and identity claims (business development company, registered investment adviser, family office, venture capital, private equity), lending ('X is a lender to Y', 'Y's lenders include X'), dated positions ('X held a position in Y as of 2025-06-30', with a fair value or principal), and advisor moves ('P moved from firm A to firm B in 2023'). A BDC's filed schedule is a complete list of its holdings, so a lending or position claim it does not carry for that date (or, in the present tense, on its latest schedule) is CONTRADICTED; a stated amount or year is checked against the document. Property facts are outside them. 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
yearNo
as_ofNoISO date the claim is about, for lending and position claims that do not state one.
claimNo
objectNo
subjectNo
predicateNo
object_dfx_idNoA 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.
subject_dfx_idNoA 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / as_of
      Added value: +{
+  "description": "ISO date the claim is about, for lending and position claims that do not state one.",
+  "type": "string"
+}
    • changedInput schema / properties / predicate / enum
      Previous value: -[
-  "INVESTED_IN",
-  "ACQUIRED",
-  "CO_INVESTED_WITH",
-  "WORKS_AT",
-  "IS_A",
-  "ADVISER_OF",
-  "COMMITTED_TO"
-]New value: +[
+  "INVESTED_IN",
+  "ACQUIRED",
+  "CO_INVESTED_WITH",
+  "WORKS_AT",
+  "IS_A",
+  "ADVISER_OF",
+  "COMMITTED_TO",
+  "LENDER_TO",
+  "HOLDS_POSITION",
+  "MOVED_FIRM"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / predicate / enum
      Previous value: -[
-  "INVESTED_IN",
-  "ACQUIRED",
-  "CO_INVESTED_WITH",
-  "WORKS_AT",
-  "IS_A"
-]New value: +[
+  "INVESTED_IN",
+  "ACQUIRED",
+  "CO_INVESTED_WITH",
+  "WORKS_AT",
+  "IS_A",
+  "ADVISER_OF",
+  "COMMITTED_TO"
+]
  3. Changed2 schema fields changed
    • changedInput schema / properties / object_dfx_id / description
      Previous value: -"A DFX id: dfx:fo:<uuid> (family office graph), dfx:isi:<uuid> (sponsor graph), dfx:vc:<uuid> (venture graph), dfx:pe:<uuid> (private equity graph), or a bare real estate UUID."New value: +"A 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."
    • changedInput schema / properties / subject_dfx_id / description
      Previous value: -"A DFX id: dfx:fo:<uuid> (family office graph), dfx:isi:<uuid> (sponsor graph), dfx:vc:<uuid> (venture graph), dfx:pe:<uuid> (private equity graph), or a bare real estate UUID."New value: +"A 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."
  4. Changed2 schema fields changed
    • changedInput schema / properties / object_dfx_id / description
      Previous value: -"A DFX id: dfx:fo:<uuid> (family office graph), dfx:isi:<uuid> (sponsor graph), dfx:vc:<uuid> (venture graph), or a bare real estate UUID."New value: +"A DFX id: dfx:fo:<uuid> (family office graph), dfx:isi:<uuid> (sponsor graph), dfx:vc:<uuid> (venture graph), dfx:pe:<uuid> (private equity graph), or a bare real estate UUID."
    • changedInput schema / properties / subject_dfx_id / description
      Previous value: -"A DFX id: dfx:fo:<uuid> (family office graph), dfx:isi:<uuid> (sponsor graph), dfx:vc:<uuid> (venture graph), or a bare real estate UUID."New value: +"A DFX id: dfx:fo:<uuid> (family office graph), dfx:isi:<uuid> (sponsor graph), dfx:vc:<uuid> (venture graph), dfx:pe:<uuid> (private equity graph), or a bare real estate UUID."
  5. Added

TDQS

A4.1/5.0
Behavior5/5

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

With readOnly/idempotent/closed-world already in annotations, the description still adds substantial behavior: SUPPORTED always carries a cited evidence row, a name resolves only to a record bearing that name (else UNKNOWN with candidates), absence of evidence is never CONTRADICTED, and a BDC schedule is treated as complete so omitted holdings are CONTRADICTED. It also discloses the paywall truncation model (first 5 rows, locked.count/by_type, withheld contact values) and that every answer reports withholdings in `entitlement` and `locked` — none of which annotations cover.

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?

The substance is front-loaded and dense with genuinely load-bearing rules, but it is one long run-on block mixing semantics, access tiers, and a commercial footer ('Full access: DFX Intelligence, 7 days free at ...') that does not help an agent decide whether to call the tool. Splitting the entitlement mechanics into a short clause and dropping the sales line would sharpen it.

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 8 loosely-specified parameters, the description carries the return contract itself — verdict plus evidence plus `entitlement` / `locked` — which is what an agent needs to interpret results. The main residual gap is interplay between the free-text `claim` and the structured fields, and when PARTIALLY_SUPPORTED is chosen rather than SUPPORTED or CONTRADICTED.

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 only 38%, so the description must compensate, and it largely does: it explains the two input modes (a free-text `claim` sentence vs. a structured subject/predicate/object/year set), implies `as_of` from the dated-position examples ('as of 2025-06-30', latest schedule for present tense), and its prose predicate list maps onto the enum values. It does not say whether claim and structured fields can be mixed or which wins on conflict.

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?

The description states a concrete operation: return one of four verdict labels (SUPPORTED / PARTIALLY_SUPPORTED / CONTRADICTED / UNKNOWN) for a claim, with supporting observations. Combined with the title this is unmistakable, and it is clearly distinct from the search_* and resolve_* siblings. It leads with output labels rather than a verb, but the resource and outcome are never in doubt.

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 real when-to-use context by enumerating the claim families the predicates cover (investment, acquisition, adviser, commitment, identity, lending, dated positions, advisor moves) and explicitly excludes property facts ('Property facts are outside them' — route those to get_property_record / search_parcels). It also fixes the decision rule between CONTRADICTED and UNKNOWN. It stops short of naming a specific alternative tool for the excluded or name-resolution cases.

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