Skip to main content
Glama

Search independent sponsors

search_independent_sponsors
Read-onlyIdempotent

Verified independent sponsor firms (deal-by-deal acquirers of lower middle market companies) as compact cards: verification status, classification, mandate summary, principals, vehicle count and latest vehicle, and how many companies resemble the sponsor's observed deals. Only firms whose identity evidence names them (eligibility VERIFIED_SPONSOR_FIRM) are returned unless include_unverified is true, which returns the unverified filing groups and candidates as a labelled research list. With sector, the answer is OBSERVED behaviour: verified sponsors with observed deals in that vertical first. Returns dfx:isi: ids. Capital providers and target companies are not in these results. 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

TableJSON Schema
NameRequiredDescriptionDefault
cityNo
kindNo
sortNo
limitNo
queryNo
stateNoTwo-letter US state code.
sectorNoFree text mapped onto the eight verticals (business_services, industrial_manufacturing, industrial_services, healthcare_services, consumer_services, specialty_distribution, transportation_logistics, tech_enabled_services); text that maps to none is matched against the mandate summary.
min_confidenceNo
include_unverifiedNotrue returns the research list instead: unverified Form D filing groups and candidates, never paired with companies. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / include_unverified
      Added value: +{
      +  "description": "true returns the research list instead: unverified Form D filing groups and candidates, never paired with companies. Default false.",
      +  "type": "boolean"
      +}
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare a safe read-only, idempotent, closed-world profile, yet the description adds substantial non-schema behavior: the entitlement/locked model (first 5 rows + counts, never the rest), that contact values and decision-maker names are never returned, and that every answer discloses withholding via `entitlement` and `locked`. This is far beyond what the annotations convey.

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?

Dense but front-loaded: entity definition first, then eligibility, then sector behavior, then access model. Nearly every sentence carries load, though the closing plan-promotion line is more pitch than agent-relevant signal and the paragraph is long for a single block.

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 9 optional params, the description does the heavy lifting on returns (compact cards, id format) and the access/withholding model. It is strong on behavioral completeness but light on the remaining query parameters, leaving a modest gap for an agent tuning a search.

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 low (33%), and the description only meaningfully elaborates `sector` (OBSERVED behaviour, vertical mapping) and `include_unverified` (research list semantics). Parameters like kind, sort, min_confidence, limit, city, and query receive no explanatory treatment, so it only partially compensates for the coverage gap.

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+resource and defines the entity precisely ("Verified independent sponsor firms (deal-by-deal acquirers of lower middle market companies)"). It also clarifies scope boundaries ("Capital providers and target companies are not in these results") and returns an id namespace (dfx:isi:), distinguishing it from get_independent_sponsor and the sponsor-deal siblings.

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?

Gives concrete when-to-use conditions: only verified firms are returned unless include_unverified is true, which switches to a labelled research list; with `sector` the result becomes OBSERVED behaviour ordering. It does not explicitly name sibling alternatives (e.g. search_isi_opportunities vs search_sponsor_deals), so routing between near-neighbors is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.