Skip to main content
Glama

Fintel Discovery — Financial Intelligence for AI Agents

Get SEC Form ADV Detail by CRD

GetIAPDFirmDetail
Read-onlyIdempotent
    Retrieve the full Form ADV filing detail for one RIA firm by its CRD number.
    Returns all Form ADV Part 1 fields: client types, advisory activities, fee
    arrangements, custody information, office locations, and affiliated entities.

    Use this tool when:
    - You have a firm CRD (from SearchIAPDFirm) and want complete ADV detail
    - You need office locations, custodians, or affiliated BD information
    - You are building a detailed profile for a prospect RIA firm

    Source: SEC IAPD public API. No API key required.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds useful behavioral context: the source (SEC IAPD public API) and that no API key is required. It also lists the fields returned, giving the agent a preview of the output. No contradiction with annotations.

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 description is compact and front-loaded with the operation, followed by a cleanereturn-fields list, a 'Use this tool when' bullet section, and a source note. There is minor redundancy (CRD mentioned twice) but every sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers what data is returned, the source, auth requirements, and common use cases. However, the schema marks crd as optional with default null, while the description implies the CRD is required, creating potential ambiguity. It also does not say what happens if the CRD is invalid or not found. Output schema and annotations fill some gaps but not this one.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the description provides almost no parameter-level detail. The schema itself already documents CRD and the other nested parameters thoroughly, so the description's 'byits CRD number' is redundant and adds no new meaning. The description does not compensate for the low coverage level.

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 specific verb ('Retrieve') and resource ('ull Form ADV filing detail') with a clear scope ('one RIA firm by its CRD number'). It also lists the key fields returned, making the purpose unambiguous. It does not explicitly name a sibling tool to differentiate from, though the title 'Detail by CRD' implies contrast with search tools like SearchIAPDFirm.

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?

The 'Use this tool when' section provides three specific conditions, including the prerequisite of having a CRD from SearchIAPDFirm and the use cases of needing offices, custodians, or affiliate BD info. It does notexplicitly state when not to use it or name alternatives, but the guidance is clear enough for an agent.

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.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools target a distinct resource and action, with clear separation between search and detail tools (e.g., SearchIAPDFirm vs GetIAPDFirmDetail, SearchBrokerCheck vs GetBrokerCheckDetail). A few pairs like SearchBrokerCheck and SearchBrokerCheckFirm could cause momentary confusion, but descriptions clarify individual vs firm scope.

Naming Consistency4/5

The dominant pattern is consistent: Search* for discovery, Get* for retrieval, with CamelCase throughout. Minor deviations like LookupTicker and MapInstrumentIds introduce different verbs, and SearchBrokerCheck does not explicitly signal 'individual' unlike SearchBrokerCheckFirm, but the overall convention remains predictable.

Tool Count2/5

With 32 tools, the surface is quite heavy and exceeds the 25+ threshold for 'too many.' While the financial intelligence domain is broad, several search/detail pairs and overlapping data-source tools could be consolidated to reduce cognitive load for agents.

Completeness4/5

The toolset covers major workflows well: 13F holdings, fund fee comparison, advisor due diligence, macro data, price history, options, and identifier mapping. Minor gaps exist, such as no standalone real-time quote tool, no news/sentiment data, and no direct CUSIP-to-company-name search, but these are workable around.

Resources