Skip to main content
Glama

FinBridge

Get Institutional Holdings (SEC Form 13F)

get_edgar_13f
Read-only

Latest institutional-manager holdings from a SEC Form 13F-HR filing, aggregated by security with quarter-over-quarter (QoQ) changes. Filer-centric: answers "what does hold?" for a named institutional investment manager (e.g. Berkshire Hathaway, Bridgewater). It does NOT answer "who owns ?" — 13F info tables key securities by CUSIP + issuer name, not ticker.

Args:

  • filer (required): institutional manager NAME ('Berkshire Hathaway Inc', 'Bridgewater Associates') or CIK number ('1067983'). NOTE: 13F managers are not in the ticker map, so an issuer ticker (AAPL) will not resolve here — use the manager's name or CIK.

  • top: number of largest holdings (by value) to return, 1-50 (default 20). QoQ changes are likewise capped at this count, most material first.

  • response_format: 'markdown' (default) or 'json'

Returns: {filer:{name, cik}, period (YYYY-MM-DD quarter end), filed, total_value (whole USD), num_holdings (distinct CUSIPs), value_unit:'USD', holdings:[{issuer, cusip, class, shares, value, pct_of_portfolio}], prior_period?, changes:[{issuer, cusip, action, delta_shares, new_shares, prior_shares}], notes}. action: new=opened, added=increased, reduced=trimmed, sold=fully exited. Multiple info-table rows per issuer (one per sub-manager) are summed by CUSIP.

Examples:

  • "What does Berkshire hold?" -> {filer:'Berkshire Hathaway Inc'}

  • "Bridgewater's top 10 positions and QoQ moves" -> {filer:'Bridgewater Associates', top:10}

  • "Berkshire 13F by CIK" -> {filer:'1067983'}

Use when: you want a specific institutional manager's disclosed US equity portfolio and how it changed since the prior quarter. Don't use for: insider trades (get_edgar_insider_trades / Form 4), a reverse "which funds own ticker X" view (not supported — CUSIPs are not mapped to this server's ticker universe), Korean holdings, or intra-quarter/real-time positions.

Caveats: value is reported in whole USD for filings on/after 2023-01-03 and in thousands before (normalized here to whole USD; a note flags conversions). 13F covers only long US-listed 13(f) securities — no shorts, options detail, cash, or non-US holdings — and is filed up to 45 days after quarter-end. Not investment advice.

Errors: unknown filer -> ToolError (only 13F filers covered; use the exact name or CIK); ambiguous name -> ToolError listing candidate managers with CIKs; a manager filing 13F-NT only -> ToolError explaining no holdings table exists.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topNoNumber of largest holdings by value to return (default 20)
filerYesInstitutional manager name ('Berkshire Hathaway Inc', 'Bridgewater Associates') or CIK number ('1067983')
response_formatNo'markdown' for tables, 'json' for compact machine-readable outputmarkdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
filedNo
filerYes
notesNo
periodNo
changesYes
holdingsYes
value_unitNo
total_valueNo
num_holdingsNo
prior_periodNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark this read-only and open-world, and the description adds substantial behavioral context: CUSIP-level aggregation/summing, 45-day filing lag, value normalization from thousands to whole USD, coverage limits (long US-listed 13(f) securities only), and specific ToolError cases. No contradiction with annotations.

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 long but logically structured into labeled sections (Args, Returns, Examples, Use when, Don't use, Caveats, Errors), making it easy for an agent to scan. The only minor issue is some repetition of the ticker-resolution warning, though it is defensible emphasis for a common failure mode.

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?

For a tool with one required parameter, rich annotations, and an output schema, the description covers invocation, parameter semantics, examples, failure modes, and data caveats comprehensively. Nothing an agent needs to decide whether to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description still adds real value: filer gets examples plus the critical caveat that issuer tickers will not resolve; top gets its 1-50 range and the behavior of capping QoQ changes; response_format gets clarity on markdown vs json. This far exceeds the baseline.

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: 'Latest institutional-manager holdings from a SEC Form 13F-HR filing, aggregated by security with quarter-over-quarter changes.' It also explicitly distinguishes the tool's filer-centric scope from a reverse 'who owns <ticker>?' lookup, clearly separating it from sibling EDGAR tools.

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?

Provides explicit 'Use when' and 'Don't use for' sections, including a direct pointer to get_edgar_insider_trades / Form 4 as the alternative for insider trades. It also lists concrete exclusions (Korean holdings, intra-quarter/real-time positions) and notes the unsupported reverse lookup.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation4/5

Most tools have clearly distinct resource+action targets, and the overlapping screen_* tools are thoroughly cross-referenced with 'use screen_X instead' guidance. Minor ambiguity exists between get_disclosure_feed, get_dart_filings, and get_dart_major_events, which all surface KR filings from different angles but remain distinguishable.

Naming Consistency5/5

Every tool follows a consistent verb_noun snake_case pattern: get_* for retrievers, screen_* for screeners, search_* for lookups, plus action verbs like analyze_, backtest_, compare_, import_, and query_. Subfamilies (dart_*, edgar_*, fred_*, crypto_*) are consistently prefixed, making tool selection predictable.

Tool Count3/5

37 tools is heavy, and the four momentum screeners (canslim/kell/minervini/schwartz) plus three KR disclosure tools could arguably be collapsed into parameterized variants. However, the server's unusually broad scope—KR/US/TW/JP/EU equities, crypto, macro, portfolio, backtesting—means most tools earn their place, so the count is high but not chaotic.

Completeness4/5

The surface covers the core workflow well: search, prices, fundamentals, filings, insider trades, valuation, screeners, backtesting, and portfolio tracking for KR/US, plus crypto and macro. Notable gaps are the lack of single-company financial-statement tools for TW/JP/EU (only available through screen_companies) and no real-time stock quotes, but these are workable for the stated local-database research purpose.

Resources