Fintel Discovery — Financial Intelligence for AI Agents

Get GLEIF LEI Detail

GetLEIDetail

Read-onlyIdempotent

    Retrieve the full GLEIF LEI record for one legal entity using its
    20-character LEI code. Returns legal name, registration status, legal
    address, headquarters address, managing LOU, and renewal dates.

    Use this tool when:
    - You have a LEI (from SearchLEI) and need full entity details
    - You want to verify the registration status and renewal date
    - You need the exact legal address and jurisdiction of an entity

    Source: GLEIF API (api.gleif.org). No API key required.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict them. The description adds useful context beyond annotations: it names the external GLEIF API as the source, states that no API key is required, and enumerates the returned data fields. This is sufficient for a simple read-only lookup.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: purpose comes first, followed by concrete use cases and source/authentication note. Every sentence adds value, and there is no fluff or repetition of the tool name.

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?

For a simple single-entity lookup, the description covers purpose, use cases, and return fields well. However, given the unusual number of irrelevant-looking schema parameters and 0% schema coverage, it should have explicitly stated that only the LEI is required for normal use. That omission creates a meaningful completeness gap for an AI agent deciding how to invoke the tool.

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?

The description only explains the meaning of the LEI code itself, which is the primary parameter, but the input schema contains several additional parameters (wholesaler_ids, source_resource_id, question_asked, etc.) with zero schema description coverage according to the context signals. An agent could easily be confused about whether those parameters are relevant to this GLEIF lookup. The description does not clarify that only lei is needed and the rest are internal or optional plumbing.

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 description uses a specific verb and resource: 'Retrieve the full GLEIF LEI record for one legal entity using its 20-character LEI code.' It clearly separates this from sibling search tools like SearchLEI by focusing on single-record detail retrieval. The listed return fields make the tool's scope unambiguous.

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 description explicitly states when to use the tool: when a LEI is already available from SearchLEI, when verifying registration status/renewal date, and when needing exact legal address/jurisdiction. It does not explicitly say 'do not use this to search by name,' but the reference to SearchLEI as the source of the LEI implies the boundary.

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

All Fintel Discovery — Financial Intelligence for AI Agents tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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

Need Help?