Skip to main content
Glama

SEC EDGAR Fundamentals

One Company's Insider Transactions

issuer_insider_activity

Every Form 3, 4 and 5 row filed against one company — identified by ticker — by its directors, officers and ten-percent owners, newest transaction first. Returns transaction rows, one per filed row, each carrying the transaction code with its plain-language meaning, the acquired or disposed direction read from the filing's own flag rather than inferred from the code, the shares, the value the filing stated, the position held afterwards, and Rule 10b5-1 status where the filing states it. Reach for this when the question is about one company: who among its insiders has been buying or selling, whether a disposal was an open-market sale or shares withheld against an option exercise, which executives filed a Form 4 last month. Optional date-range, transaction-code, direction and row-kind filters narrow the read before it is paid for. For the same question across every issuer at once use screen_insider_transactions; for one row per person with the totals already rolled up use screen_insiders. A Form 4 is filed within two business days of its transaction and a Form 5 annually, so these rows trail the trades they describe. See /.well-known/x402 for current pricing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoOne Form 3/4/5 transaction code to match, such as P for an open-market purchase, S for an open-market sale, A for a grant, M for an option exercise or F for shares withheld against an exercise obligation or a tax liability. list_ownership_codes publishes the whole vocabulary free. Omit to match every code.
limitNoTransaction rows per page, newest first. Accepts 1 to 100; defaults to 50 when omitted. The ceiling cannot be raised by a parameter and is published in the response.
offsetNoRows to skip before this page, for paging through a result set. Accepts 0 to 5000; defaults to 0. Narrow the filters rather than paging deeper.
tickerYesExchange ticker symbol of a single SEC filer, case-insensitive, such as AAPL, MSFT or KO.
end_dateNoLatest transaction date to include, inclusive, as YYYY-MM-DD. Leave it out for an open-ended range running to the newest row in the corpus.
row_kindNoRestrict to 'transaction' rows, which report an event, or 'holding' rows, which report a position — a Form 3 reports holdings, and counting one as activity would read as a purchase on the day somebody joined. Omit to receive both.
directionNoRestrict to acquisitions ('A') or disposals ('D'), read from the filing's own acquired/disposed flag and never derived from the transaction code. A code and a direction disagree routinely: an option exercise disposes of the derivative security while acquiring common stock. Omit to match both.
start_dateNoEarliest transaction date to include, inclusive, as YYYY-MM-DD. Matched against the date the transaction happened, not the date the filing arrived — the two differ by days on a Form 4 and by up to a year on a Form 5.

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key traits: one row per filed row, direction read from the filing's own flag rather than inferred from the code, inclusion of filing-stated values and Rule 10b5-1 status, newest-first ordering, and the lag between trades and filings. This goes well beyond a simple read/write label.

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 dense but every sentence earns its place: main behavior, return-row semantics, example use cases, sibling routing, data-latency caveat, and pricing pointer. Despite its length, it front-loads the most decision-relevant facts and avoids repetition or 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?

With no output schema, the description explains what each returned row carries: transaction code with plain-language meaning, direction, shares, value, position after, and 10b5-1 status. It also covers ordering, filing lag, filter options, and pricing, leaving no major gap an agent would need to guess about when selecting or invoking the tool.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents each parameter's meaning, defaults, and constraints. The description adds contextual framing about narrowing the read 'before it is paid for' and the distinction between transaction date and filing date, but it does not add new parameter-level meaning beyond the schema's own detailed 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 starts with a clear, specific statement: 'Every Form 3, 4 and 5 row filed against one company — identified by ticker — by its directors, officers and ten-percent owners.' It explicitly names the resource (one company's insider transactions), conveys the verb (returns/list), and distinguishes itself from siblings like screen_insider_transactions and screen_insiders.

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?

It gives explicit usage guidance: 'Reach for this when the question is about one company' and names the alternatives with conditions: 'For the same question across every issuer at once use screen_insider_transactions; for one row per person with the totals already rolled up use screen_insiders.' It also explains when filters are appropriate and that rows trail trades due to filing deadlines.

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.3/5.0
Disambiguation5/5

Every tool targets a distinct resource and action: company reference, financial statements, single-metric history, cross-company comparison, filing history, insider transactions, insider aggregation, and vocabulary lookup. Cross-references between insider tools make boundaries explicit and prevent misselection.

Naming Consistency4/5

Names are all snake_case and mostly follow predictable verb_noun conventions like get_*, list_*, and screen_*. A few noun-phrase names (company_profile, insider_profile, issuer_insider_activity) and adjective-noun names (latest_insider_filings) break the strict pattern, but the meaning remains clear.

Tool Count5/5

Twelve tools is well within the ideal range for a focused SEC EDGAR fundamentals server. Each tool covers a meaningful slice of either financial data or insider ownership data, and none feels redundant or unnecessary.

Completeness4/5

The server covers the core read-only workflows well: company identity, normalized financials, metric history, cross-company comparison, filing history, insider transactions, insider profiles, and vocabulary support. Minor gaps exist—no company search by name/CIK and no raw filing text retrieval—but common fundamental and insider questions can be answered without dead ends.

Resources