List institutional investors holding US spot crypto ETFs (Bitcoin ETF complex), ranked by total USD held, from the latest quarter of SEC 13F filings. Optionally filter to holders of a specific ETF via the product parameter (e.g. 'IBIT').
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| limit | No | Results per page | |
| product | No | Filter to holders of a specific spot crypto ETF ticker, e.g. 'IBIT', 'FBTC', 'GBTC'. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the data comes from the latest quarter of SEC 13F filings (implying quarterly data), and that results are ranked by total USD held. It does not describe pagination behavior or rate limits, but the schema covers pagination parameters. The description is honest about its read-only nature and data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The verb and resource are front-loaded. Every word earns its place. It is appropriately concise for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, data source, ranking, and optional filtering. It lacks explanation of the return format (fields like institution name, holdings, etc.) since there is no output schema. However, for a list tool with parameter schema coverage, it is fairly complete. It could mention the specific ETF complex (Bitcoin ETF) more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all three parameters described. The description reinforces the product filter with an example ('IBIT'), but does not add significant meaning beyond the schema. For page and limit, it adds no new information. Baseline 3 is appropriate as the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'institutional investors holding US spot crypto ETFs', the ranking criterion 'total USD held', and the data source 'latest quarter of SEC 13F filings'. It distinguishes itself from siblings like get_crypto_holder (singular) and get_crypto_exposure by specifying it's a ranked list of all holders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional filtering by product, implying when to use specific parameters. However, it does not explicitly state when to use this tool versus other sibling tools (e.g., get_crypto_holder for a single holder). It provides clear context but lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource and action, and descriptions explicitly disambiguate similar pairs (e.g., get_congress_member vs get_congress_trades, get_crypto_holder vs get_crypto_holders). No two tools appear to do the same thing.
The dominant pattern is get_<noun>, with list_<noun> for enumerations. Minor deviations exist: a bare 'search' tool and the 'sec_' prefix on SEC filing tools break the uniform verb_noun style, but the pattern remains predictable.
At 24 tools, this is on the heavier side, but the server spans multiple financial data domains (SEC filings, stocks, insider trading, crypto, rates, economics), so each tool has a clear purpose. It is just below the 'too many' threshold.
The tool surface is remarkably complete for financial data retrieval: SEC filing lifecycle is covered (list -> index -> document), institutional ownership is available from both stock and institution perspectives, and insider/congress/crypto/economic data are all present. No obvious gaps or dead ends.