Skip to main content
Glama

beatandraise.com SEC Filings

Get Insider Transactions

get_insider_transactions
Read-onlyIdempotent

Get parsed Form 4 insider transactions for a company.

Returns insider buy/sell transactions with owner details (name, title, relationship), transaction details (date, code, shares, price), and post-transaction holdings. Data is extracted from the Form 4 XML.

Transaction codes: P=Purchase, S=Sale, A=Award, M=Exercise, G=Gift, F=Tax (shares withheld to pay tax on a vesting or exercise, not a sale by choice).

Every row carries plan_10b5_1: the filing's Rule 10b5-1 checkbox as filed (true, false, or null for filings from before the box existed in 2023). It is the filer's declaration for the whole filing. Filers sometimes leave it unticked and name a plan in a footnote (common for plans adopted before 2023), or tick it without one, so before saying a sale was or was not under a plan, read the footnotes (include_footnotes=True). An S alone does not tell a planned sale from a discretionary one.

With include_footnotes=True each row also lists the footnotes it points to ({id, text}, as filed): plan adoption dates, the price range behind a weighted average price, shares sold to cover taxes, trusts and other indirect holdings. Covers filings from coverage_from (2024-01-01).

By default only Form 4 Table I (the shares themselves) is returned. With include_table_ii=True, Table II lines are added and every row says which table it is from ("I" or "II"); Table II rows also give the underlying security, exercise price and dates. Table II is what the SEC calls "derivative securities" for Section 16: stock options, but also RSUs, PSUs and convertible share classes, which are compensation or share classes, not derivatives in the usual sense, so describe them by their security_title. An RSU vesting appears in both tables (an M disposal of units in II, an M acquisition of shares in I): count it once. A grant (A) is compensation, not a purchase. Table II covers filings from coverage_from (2024-01-01).

Args: cik: Issuer CIK — the company whose insiders are trading (e.g. "320193" for Apple) from_date: Start date (YYYY-MM-DD) to_date: End date (YYYY-MM-DD) limit: Max filings to process (1-100, default 20) offset: Pagination offset include_table_ii: Also return Table II lines: options, RSUs and the like (default False) include_footnotes: Also return each line's footnotes (default False)

Input Schema

NameRequiredDescriptionDefault
cikYes
limitNo
offsetNo
to_dateNo
from_dateNo
include_table_iiNo
include_footnotesNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare a safe read-only, idempotent, non-destructive operation, but the description adds substantial behavioral context: default Table I-only output, Table II behavior, footnote inclusion, coverage boundaries, transaction-code meanings, and caveats such as counting RSU vestings once. It also warns about the limitations of plan_10b5_1, which is exactly the kind of nuance an agent needs before interpreting results.

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 with purpose and is generally information-dense, but it is long and repeats the coverage_from date in two sections. Most sentences earn their place because the financial/legal caveats are useful, though the length could be trimmed slightly.

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, the output schema, and the annotations, the description is complete. It covers data source, coverage period, default versus optional output, transaction codes, footnote behavior, Table II semantics, and interpretation caveats, leaving no critical gap for correct invocation or interpretation.

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 parameter meaning, and it does: every parameter is documented in the Args section, including CIK meaning, date ranges, limit as max filings, offset pagination, and the precise effect of include_table_ii and include_footnotes. This fully compensates for the lack of schema descriptions.

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 states a specific verb and resource: get parsed Form 4 insider transactions for a company, with source data from Form 4 XML. This is clearly distinct from sibling tools such as get_holdings and get_institutional_holders, and an agent can identify the tool without opening the schema.

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 gives clear operational guidance for optional parameters, especially when to use include_footnotes and include_table_ii, and explains the coverage start date. It does not explicitly compare this tool to sibling tools or state when not to use it, so it falls short of the highest level.

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