Skip to main content
Glama

filingpulse

by io.filingpulse
OverviewDiscussionsAdmin

Insider ownership filings (Forms 3/4/5)

get_insider_trades
Read-only

List normalized SEC insider ownership filings (Form 4 transactions, plus Form 3 initial statements and Form 5 annual statements — 3/5 live-forward since 2026-09-23), newest first: non-derivative and derivative transaction legs, holdings, owner roles (director/officer/10% owner), footnotes, and amendment (/A) links. Numeric values are strings exactly as filed; every object carries 'accession' and 'filed_date'. Filter by issuer ticker, issuer CIK, reporting-owner CIK (owner_cik — one insider's filings across every issuer), form_type, or since-date. Returns a {data, total, limit, offset} envelope for paging. Hosted and already normalized — no EDGAR crawling, parsing, or local install needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cikNoSEC CIK number, digits only (leading zeros optional).
limitNoRows to return (max 25 on this endpoint).
sinceNoOnly filings filed on/after this date (YYYY-MM-DD).
untilNoOnly filings filed on/before this date (YYYY-MM-DD) — with since, a fixed reproducible window.
offsetNoRows to skip — page through 'total' with limit+offset.
tickerNoIssuer ticker symbol as filed, e.g. KMI. Case-insensitive exact match.
form_typeNo3 = initial ownership, 4 = transactions, 5 = annual statement; /A = amendment. Forms 3/5 are live-forward since 2026-09-23.
owner_cikNoReporting owner (insider) CIK, digits only — one person or entity's filings across every issuer. Owner CIKs appear in each filing's reporting_owners[].

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / form_type / description
      Previous value: -"4 = original filing, 4/A = amendment."New value: +"3 = initial ownership, 4 = transactions, 5 = annual statement; /A = amendment. Forms 3/5 are live-forward since 2026-09-23."
    • changedInput schema / properties / form_type / enum
      Previous value: -[
-  "4",
-  "4/A"
-]New value: +[
+  "3",
+  "3/A",
+  "4",
+  "4/A",
+  "5",
+  "5/A"
+]
  2. Changed1 schema field changed
    • addedInput schema / properties / owner_cik
      Added value: +{
+  "description": "Reporting owner (insider) CIK, digits only — one person or entity's filings across every issuer. Owner CIKs appear in each filing's reporting_owners[].",
+  "pattern": "^\\d{1,10}$",
+  "type": "string"
+}
  3. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses important behavioral details: numeric values are returned as strings exactly as filed, every object includes accession and filed_date, and responses use a {data, total, limit, offset} paging envelope. It also notes the live-forward date cutoff for Forms 3/5 and the normalized/hosted nature of the data. These details help an agent correctly interpret results without needing to make assumptions about data types or structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently organized: it front-loads the action and resource, then details response contents, filters, paging, and a value proposition in four sentences. Every sentence adds meaningful information without repetition or fluff. The structure allows an agent to quickly extract the core function and important caveats.

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?

Even without an output schema, the description covers the essential return structure, data-typing quirks, sorting, filtering options, and pagination. It gives enough detail for an agent to invoke the tool and interpret the response correctly. The only omissions, such as rate limits or auth requirements, are outside the intended scope and not contradicted by annotations.

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?

With 100% schema description coverage, the baseline is 3. The description adds a useful clarification that 'cik' refers to the issuer CIK (the schema only says 'SEC CIK number'), and it reiterates the cross-issuer semantics of owner_cik. It does not add much for the other parameters, but the issuer CIK disambiguation justifies a 4.

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 clearly states 'List normalized SEC insider ownership filings' with specifics on form types, ordering, and contents. This distinguishes it from sibling get_insider_filing, which suggests a single-filing tool, by emphasizing the list/paging behavior. The coverage of form variants and filters leaves no ambiguity about the tool's function.

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?

The description provides clear context: an agent should use this tool to retrieve filtered lists of SEC insider ownership filings, with explanation of the available filters and paging envelope. It does not explicitly name alternative tools or exclusions, but the 'List' verb and the mention of 'no EDGAR crawling' make the intended use case evident. Lacking an explicit 'when not to use' reference is a minor gap.

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

All filingpulse 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