Skip to main content
Glama

secedgar-mcp-server

by io.github.cyanheads

Find Holders

secedgar_find_holders
Read-onlyIdempotent

Find which institutional managers reported holding an issuer, by searching 13F-HR information tables for one reporting quarter. This is the reverse direction of secedgar_get_institutional_holdings: that tool takes a manager and returns its portfolio, this one takes an issuer and returns its managers — pass a returned filer_cik plus the same quarter to read the actual position. Searching by cusip is the precise path, matching the identifier the information table itself carries; without it the issuer name is matched as a phrase against the filing text, which both over-matches (unrelated issuers sharing a word) and under-matches (managers writing the name differently), so prefer cusip whenever one is known. A CUSIP cannot be derived from a ticker here — read one off any 13F information table returned by secedgar_get_institutional_holdings. The returned list is unranked: the search index scores by text relevance, which carries no signal about position size, and no ordering by shares or market value is available without opening each filing. Managers holding under $100M in 13(f) securities are exempt from filing at all.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cusipNoThe issuer's 9-character CUSIP (e.g. "037833100" for Apple common stock; foreign issuers use a CINS starting with a letter, e.g. "H1467J104"). The precise match key — information tables identify every position by CUSIP, so this avoids the name-phrase misses. Each share class has its own CUSIP, so a multi-class issuer needs one call per class. Read a CUSIP off the holdings returned by secedgar_get_institutional_holdings.
limitNoFiler rows returned inline. The full fetched set (up to 500 rows) is materialized as a dataframe when a canvas is available. Default 20.
issuerYesThe portfolio company whose holders you want — a ticker ("AAPL"), a 10-digit CIK ("0000320193"), or a company name. Without cusip, this resolves to the company's EDGAR-conformed name and that name is phrase-matched against 13F information tables, so it must identify one company. With cusip supplied, it is used only to label the result.
quarterNoReporting quarter to search, "YYYY-QN" (e.g. "2026-Q1"). Omit for the newest quarter whose 45-day filing deadline has passed — the applied quarter and its filing window are echoed in the response. A quarter still inside its deadline returns nothing, because the filings do not exist yet.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe limit cap applied.
errorNoPresent when the call failed. Absent on success.
shownNoNumber of filers shown inline.
issuerNoThe issuer input, echoed.
noticeNoGuidance when the search returned no filers — names the likely cause.
datasetNoCanvas dataframe holding every fetched filer row, each carrying the issuer key and quarter so it joins across issuers and quarters. Absent when the result fits inline, canvas is unavailable, or materialization failed. Query with secedgar_dataframe_query.
fetchedNoFilings retrieved from the index, capped by the fetch budget of 500. Equals total_filings when the whole window fit inside the budget.
holdersNoOne page of filers, capped at limit. Order carries no position-size meaning — see the ordering note.
quarterNoReporting quarter searched, "YYYY-QN" — the requested one, or the applied default.
filed_toNoEnd of the filing window searched (YYYY-MM-DD).
orderingNoHow the holder list is ordered, and what that ordering does not mean.
truncatedNoTrue when the inline holders list was capped.
filed_fromNoStart of the filing window searched (YYYY-MM-DD).
search_keyNoThe exact term searched — the CUSIP, or the quoted phrase.
search_modeNoWhich key matched the information tables. "cusip" matches the identifier the table itself carries; "name" phrase-matches the filing text and is looser in both directions.
total_filingsNoTotal 13F-HR filings matching the search key inside the filing window, as reported by the index. A slight over-count of this quarter's holders on two counts, both of which the returned rows correct for: a few percent are amendments restating an older quarter, and a few more are managers amending their own report for this quarter, which puts them in the window twice.
total_is_exactNoFalse when total_filings is a lower bound (the index capped the count).
holders_in_quarterNoDistinct managers among the fetched filings reporting this quarter as their period — the set paged by limit and materialized on the dataframe. Lower than fetched by the filings dropped as amendments restating other quarters, and by managers that amended this quarter (kept once, at their latest filing).
resolved_issuer_cikNoCIK of the resolved issuer, zero-padded to 10 digits. Absent when cusip was supplied.
resolved_issuer_nameNoEDGAR-conformed company name the issuer resolved to, and the phrase that was searched. Absent when cusip was supplied (no company lookup runs).

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, which inform the agent that this is a safe, read-only, repeatable operation. The description adds valuable behavioral context beyond annotations: the search is based on text relevance, results are unranked, and it performs phrase-matching when CUSIP is absent. These details clarify what the agent can expect, though it doesn't describe pagination or the exact response structure—a minor gap. No contradiction with annotations; the readOnlyHint aligns with the description's search-oriented framing.

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 detailed but not bloated. It front-loads the core purpose and reverse-direction relationship, then systematically covers search precision, limitations, and filing exemptions. While it's longer than typical, every sentence contributes functional guidance—no filler. The structure flows logically from core purpose to key usage nuances.

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

Completeness4/5

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

The tool has four parameters, an output schema, and rich annotations. The description covers the search mechanism, precision trade-offs, limitation about ranking, and the filing exemption. The output schema likely documents the return structure, so the description needn't repeat that. Given the tool's complexity (search across 13F tables), the description adequately prepares an agent to invoke it correctly. A minor gap is explicit guidance on how to handle multi-class issuers in practice—though the description does mention 'needs one call per class'.

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 description coverage is 100%, so all four parameters are documented in the schema. The description adds meaningful semantic context beyond the schema: it explains why CUSIP is the precise match key, warns about multi-class issuers needing per-class calls, clarifies the limit parameter's behavior (inline rows vs. dataframe materialization), and explains quarter semantics. This adds real value for an agent, complementing the schema details.

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 precisely states what the tool does: finds institutional managers reporting an issuer by searching 13F-HR information tables for one quarter. It explicitly contrasts with its sibling secedgar_get_institutional_holdings (reverse direction), establishing clear differentiation. The phrasing 'takes an issuer and returns its managers' is specific and unambiguous.

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?

The description gives explicit guidance on when to use this tool versus alternatives. It directly references secedgar_get_institutional_holdings as the reverse-direction counterpart, explains that CUSIP is the preferred search path versus issuer name phrase-matching, and warns against over-matching and under-matching. It also clarifies the unranked nature of results and notes the $100M filing exemption, helping an agent decide 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 secedgar-mcp-server 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.

TDQS

A4.1/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, with detailed descriptions that explicitly separate similar-sounding ones (e.g., secedgar_get_institutional_holdings vs secedgar_find_holders vs secedgar_get_beneficial_owners). The four ownership/holdings tools share a domain but are each tied to a different filing type and direction, so an agent reading carefully should not misselect.

Naming Consistency4/5

All tools share the secedgar_ prefix and mostly follow a get_/search_/dataframe_ convention. Minor deviations like fetch_frames, compare_companies, and find_holders break the otherwise consistent verb pattern, but the naming remains predictable and readable.

Tool Count4/5

16 tools is slightly above the typical well-scoped range, but the SEC EDGAR domain is broad enough that the count is defensible. Each tool covers a distinct data source or workflow, and the dataframe management pair adds necessary infrastructure rather than bloat.

Completeness4/5

The tool set covers company lookup, full-text filing search, XBRL concepts and frames, financial histories, comparisons, insider trades, institutional holdings, beneficial owners, fund holdings, and material events. Minor gaps exist — e.g., no explicit exhibit-content retrieval and no direct way to list all filings for a company beyond recent submissions — but core workflows are well covered.

Resources