Skip to main content
Glama

beatandraise.com SEC Filings

Get 13F Holdings

get_holdings
Read-onlyIdempotent

Get parsed 13F-HR institutional holdings for a filer.

Returns individual stock positions with issuer name, CUSIP, FIGI, market value, share count, investment discretion, and voting authority, parsed from the 13F information table XML ("format": "xml"), as filed: one row per entry, values in the filer's unit (thousands of dollars for most filings before 2023, dollars since).

13F-HRs filed before SEC introduced the XML table (2013 Q2) carry their holdings as a plain-text table in the filing's own document. For those the result has "format": "text" and "text": that document as filed, paged by line (limit/offset count lines, total_lines says how many). Read the table from it; search_document on its filename finds one position. A "period_note" says when the filer's latest 13F before the period asked for is over a year older (it stopped filing).

Each holding also carries issuer_cik, sic and sic_description (the SEC's SIC industry classification of the issuer, not GICS) when the CUSIP maps to a company with a SIC. In a typical quarter that is about 87% of the value held; funds, ETFs, options and unmapped CUSIPs have none. "with_sic" in the result says how many holdings on this page were classified, so say how much of a portfolio an industry breakdown covers. Use sic_url from get_company to see peers in an industry.

Args: cik: CIK of the 13F filer / institutional investor (e.g. "1535950") period: Get holdings as of this date (YYYY-MM-DD). Returns the most recent 13F filed on or before this date. limit: Max holdings per page (1-5000, default 500) offset: Pagination offset

Input Schema

NameRequiredDescriptionDefault
cikYes
limitNo
offsetNo
periodNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare this is a safe, read-only, idempotent, non-destructive, open-world operation. The description adds substantial behavioral detail beyond that: parsed XML versus text fallback, one row per entry, units in thousands versus dollars depending on filing date, line-based paging for text results, period_note behavior, and SIC classification coverage.

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 and well structured, moving from purpose to return format to edge cases and then arguments. It is longer than strictly necessary, especially the SIC coverage statistics and get_company cross-reference, but those details are relevant and not filler.

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?

Given the tool's complexity, four parameters, 0% schema description coverage, and the presence of an output schema, the description is complete enough for an agent to call it correctly. It covers fallback text-format filings, paging behavior, period semantics, and the meaning of SIC coverage.

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 description coverage is 0%, so the description must carry all parameter semantics. It does: cik is the filer CIK with an example, period means return the most recent 13F filed on or before that date, limit is max holdings per page with range and default, and offset is pagination offset.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: get parsed 13F-HR institutional holdings for a filer, including the fields returned. It does not explicitly distinguish this tool from the sibling get_institutional_holders, so it falls short of full sibling differentiation.

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

Usage Guidelines3/5

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

The description gives useful conditional guidance for interpreting XML versus pre-2013 text-format 13F filings, including using search_document for text tables and sic_url from get_company for peer comparisons. However, it does not clearly say when to use this tool versus alternatives such as get_institutional_holders, leaving some usage choice implied rather than explicit.

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.

Resources