Skip to main content
Glama

aether-developer

by io.github.EvidInvest
OverviewDiscussionsAdmin

holdings_by_manager

Read-onlyIdempotent

What a fund owns: an institutional manager's reported equity book from SEC Form 13F — top positions by value, with quarter-over-quarter share changes and new/increased/decreased flags. Answers 'what does Bridgewater hold', 'what did this fund buy last quarter', 'show me their largest positions'. Look up by manager name (partial match; the largest matching filer wins, since names like 'Vanguard' map to several distinct CIKs) or by exact CIK. Also returns the filer's published contact details — signatory, title, phone, and business address from the filing's cover page and signature block, each citable to the accession number. EDGAR publishes no email address for 13F filers, so none is returned and none should be inferred. Coverage: quarter ends from 2024-12-31 through 2026-06-30; the newest quarter is still filling in as filers submit, and a manager who has not filed it yet falls back to their most recent quarter, named in coverage_caveat. 13F covers US-listed long equity and options only — no shorts, cash, bonds or non-US listings — and is filed 45 days after quarter end, so it is a lagged snapshot, not a live portfolio.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cikNoExact 10-digit filer CIK, e.g. 0002012383. Preferred when known.
limitNoPositions to return, 1-200 (default 25), ranked by value.
issuerNoThe company the question is about, in the same shape financial_search and search take — so an agent can carry ONE issuer object across tools. Alias only: `issuer.cik` fills in `cik` and `issuer.company_name` fills in `manager` when you have not set them. NOTE this tool identifies the FILING MANAGER, not the issuer held — for who owns a stock, use holdings_by_security. Ownership is a structured lookup, so there is no scope or quality_caveat here — `coverage_caveat` is this tool's equivalent.
periodNoQuarter end as YYYY-MM-DD. Defaults to the most recent loaded quarter.
managerNoManager name, partial match, e.g. 'Bridgewater' or 'BlackRock'. Largest matching filer wins.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile, and the description adds substantial behavioral context on top: the quarter-end coverage window, the in-progress newest quarter with fallback to a prior quarter named in coverage_caveat, the 45-day filing lag, and the explicit statement that no email is available or should be inferred.

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 and front-loaded, leading with what a 13F book is before constraints. It is long for a single description and a few clauses (signatory/contact detail list) are marginally over-detailed, but nearly every sentence carries decision-relevant information.

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

Completeness5/5

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

Covers lookup modes, coverage window, lag, fallback behavior, data limitations, and what is not returned, which is everything needed for an agent to call this correctly without an output schema. The one ambiguity it cannot resolve (exact return shape) is minor given the enumerated output fields.

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 coverage is 100% so the baseline is 3; the description nonetheless adds semantics beyond the schema, notably that partial manager names resolve to the largest matching filer and the alias behavior of issuer/manager fields. Some of this (largest matching filer) is echoed in the schema text, slightly limiting the added value.

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 ('an institutional manager's reported equity book from SEC Form 13F') and enumerates the outputs (top positions by value, QoQ share changes, new/increased/decreased flags). It explicitly disambiguates from the sibling: 'this tool identifies the FILING MANAGER, not the issuer held — for who owns a stock, use holdings_by_security.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives triggering example questions, both lookup modes (partial manager name vs exact CIK), and a named alternative with the condition that selects it (holdings_by_security for issuer ownership). Exclusion list ('no shorts, cash, bonds or non-US listings') further bounds when this tool is appropriate.

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

All aether-developer toolsInspect
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.

Resources