Skip to main content
Glama

Schedule 13D and 13G filings

get_ownership_filings
Read-onlyIdempotent

Schedule 13D and 13G filings by holders of more than 5% of a company, newest first, like livermore.club/en/ownership. 13D is filed by holders who may seek to influence the company (activists), 13G by passive holders; /A marks an amendment. Filter by form, ticker (one stock's whole history), filer_cik (an institution's or person's filings, including those it is named in), query (filer or company name, or a ticker) and filing dates. Without ticker or filer_cik the query is market-wide and limited to 365 days of filings (default: the last 30 days); note says when the range was narrowed. Each row has the company (issuer_cik, issuer_name, ticker), the filer (filer_cik, filer_name, the superinvestor name when it is one, reporting_persons in a group filing), pct_of_class and shares, the change against the previous filing of the same position (previous_pct_of_class, pct_of_class_change in percentage points, new_position), below_5_pct (an exit or a drop below the threshold), the event date, and links to livermore.club (filer_url, stock_url) and the SEC filing. Structured 13D/13G filings (voluntary since 2023-12-18, required since 2024-12-18) carry the percent, shares and event date; older SC 13D and SC 13G filings (since 2021) list only the filer, the company and the date (legacy true). Call get_data_coverage for the loaded date range. At most 200 rows per call; use page for more.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoLatest filing date, YYYY-MM-DD, inclusive.
formNo13D (holders who may seek to influence the company) or 13G (passive holders). Default: both.
fromNoEarliest filing date, YYYY-MM-DD (US Eastern).
pageNoPage number starting at 1; each page has `limit` rows. Check has_more.
limitNoMaximum rows to return (1-200, default 25).
queryNoFiler or company name contains this text, or a ticker for that company's filings (like the search box on livermore.club/en/ownership).
tickerNoOnly filings for this stock (the company's filings for this share class), whole history.
filer_cikNoOnly filings this filer submitted or is named in as a reporting person, whole history. Get the CIK from search (institutions and insiders).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
noteYes
pageYes
rowsYes
filerYes
limitYes
scopeYes
stockYes
filtersYes
has_moreYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent safety, and the description goes further: the 200-row cap and paging requirement, the note signal when the date range is narrowed, and the legacy/structured data split (percent/shares only available post-2023-12-18, legacy rows carry filer/company/date only). That is exactly the operational context an agent needs.

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?

Front-loaded with purpose, then filters, then defaults, then row shape and data caveats — a logical progression. It is long and repeats the form definitions already in the schema, but nearly every clause carries information useful for calling the tool.

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 an 8-param, zero-required, read-only search tool with pagination and heterogeneous data vintages, the description covers filtering modes, defaults, pagination limits, and data-quality caveats. With an output schema present, the row-field enumeration is a bonus rather than a gap.

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, but the description adds real meaning beyond the schema: filer_cik includes filings where the entity is merely *named* as a reporting person, ticker returns the stock's whole history, and query can match a ticker as well as a name. The restated 13D/13G definitions duplicate the schema wording.

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 (Schedule 13D/13G filings by >5% holders), scope (newest first, market-wide vs. single-entity), and anchors to a concrete analog (livermore.club/en/ownership). It is clearly separable from siblings like get_stock_13f_holders or get_superinvestor_activity.

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?

Explains when the query is market-wide and how it is then capped to 365 days (default 30), and routes the agent to get_data_coverage for the loaded range. However, it never explicitly says when to prefer this tool over get_major_holders or get_stock_13f_holders.

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