Skip to main content
Glama
Sign In

aether-developer

by io.github.EvidInvest
OverviewDiscussionsAdmin

holdings_by_security

Read-onlyIdempotent

Who owns a stock: institutional holders of a security from SEC Form 13F, ranked by position value, with quarter-over-quarter share changes. Answers 'who are the largest holders of NVDA', 'which funds added or trimmed this quarter', 'did anyone initiate a new position'. Give a ticker (resolved via CUSIP) or a CUSIP directly. Each holder row carries its accession number and an EDGAR source_url so the figure is verifiable against the primary filing. Coverage: quarter ends from 2024-12-31 on, all ~10,000 filing managers, not just large ones. The newest quarter loads daily as filings land, BEFORE its 45-day deadline, so it can be partial: the coverage object gives deadline, complete (false until deadline + 2 business days), filers_loaded vs prior_quarter_filers for this security, and a quality_caveat while partial — repeat that caveat when you report the result. Quarter-over-quarter (direction, change_shares, and the qoq roll-up with new/increased/decreased/exited counts and the largest exits) compares only filers that filed BOTH quarters, so a holder that has not filed yet is never counted as a seller. Positions are aggregated per filer CIK — a single 13F contains one line per sub-manager (BlackRock's carries 42 separate NVDA lines), so per-line reading understates holders badly. One book per filer: the original 13F-HR, or the 13F-HR/A RESTATEMENT that replaced it (add-on amendments are excluded); values are USD even where the filer reported in thousands. Note total_value_usd is the sum across filers and may double-count where combination reports include other managers' holdings; coverage_caveat flags this when relevant. 13F covers US-listed long equity and options only — it does not show shorts, cash, bonds, or non-US listings, and is filed 45 days after quarter end.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "holdings_by_security"
  }
}

Input Schema

NameRequiredDescriptionDefault
cusipNo9-character CUSIP, e.g. 67066G104. Use when the ticker is unmapped.
limitNoHolders to return, 1-100 (default 20), 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.ticker` fills in `ticker` when you have not set it. 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, e.g. 2026-09-30. Defaults to the most recent loaded quarter, which may be partial (see coverage.complete).
tickerNoTicker, e.g. NVDA. Resolved to a CUSIP internally.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / period / description
      Previous value: -"Quarter end as YYYY-MM-DD, e.g. 2026-03-31. Defaults to the most recent loaded quarter."New value: +"Quarter end as YYYY-MM-DD, e.g. 2026-09-30. Defaults to the most recent loaded quarter, which may be partial (see coverage.complete)."
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the read-only annotations, the description discloses extensive behavioral details: partial-quarter coverage before the 45-day deadline, the `coverage` object and `coverage_caveat`, quarter-over-quarter comparison methodology, CIK-level aggregation, use of the original 13F-HR or restatement rather than add-on amendments, USD normalization, double-counting caveats, and the limits of 13F coverage. These are exactly the behavioral traits an agent needs to interpret results correctly.

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 front-loaded with the core purpose and then layers in examples, input guidance, coverage caveats, and methodology. It is long, but the length is largely justified by the complexity of the ownership and coverage semantics; a minor weakness is that it reads as a dense paragraph rather than scannable sections.

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?

With no output schema, the description carries the full burden of explaining return values and does so thoroughly: holder rows include accession numbers and EDGAR source URLs, the coverage object exposes deadline and completeness, and the qoq roll-up includes direction, change_shares, and new/increased/decreased/exited counts. It also covers the major caveats needed to interpret those values correctly.

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 description coverage is 100%, so the schema already documents all five parameters including the issuer alias object, ticker-to-CUSIP resolution, period defaulting, and limit ranking. The description adds little parameter-level meaning beyond what the schema provides, so it meets the baseline rather than substantially exceeding it.

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 opens with a specific verb and resource: institutional holders of a security from SEC Form 13F, ranked by position value with quarter-over-quarter changes. It clearly distinguishes this from a manager-centric view and explains the exact questions it answers, such as largest holders of NVDA or which funds added or trimmed.

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?

It gives clear usage context through example questions and input guidance: give a ticker resolved via CUSIP or a CUSIP directly. However, it does not explicitly name the sibling holdings_by_manager or state when to choose one over the other, so the guidance is context-rich but lacks explicit alternatives.

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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources