Skip to main content
Glama

SEC EDGAR Fundamentals

Screen Insiders by Realized Proceeds, Role and Recency

screen_insiders

The same filters as screen_insider_transactions, aggregated the other way: one row per person, ranked by the cash they realized from open-market sales inside the window. This is the tool for a question about people rather than trades — which executives have been selling, who recently became liquid, which directors realized the most across every company they are an insider at — because it returns people with their totals, roles, issuers and Rule 10b5-1 coverage already rolled up instead of a list of transactions to aggregate yourself. Every total counts open-market sales only and carries the transaction codes it excluded and why, so an option exercise or shares withheld against a tax liability is never counted as somebody selling. Each row carries the owner CIK to pass to insider_profile for that person's full history. Share counts are exactly as filed and there is no wealth estimate anywhere in the answer: this service has no market data feed. A Form 4 is filed within two business days of its transaction and a Form 5 annually. See /.well-known/x402 for current pricing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleNoRestrict to filers the filing marks as a director, an officer (an executive, with their title), or a beneficial owner of more than ten percent of a class. One person can hold several of these at once. Omit to match every role.
codesNoTransaction codes to include, up to eight of them — for instance ['P'] for open-market purchases or ['P','S'] for open-market decisions in both directions. Omit to match every code. list_ownership_codes publishes the whole vocabulary with what each code actually means; filtering to codes other than S correctly yields no realized proceeds.
limitNoPeople per page, ranked by realized proceeds in the window. Accepts 1 to 50; defaults to 25. A person's row aggregates many transactions, so this page is smaller than the transaction screen's for the same work.
offsetNoPeople to skip in the ranking before this page. Accepts 0 to 199, and offset plus limit must not exceed 200: the ranking is recomputed per request, so paging deeper would re-read the window for every page. Narrow the filters instead.
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.
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.
rule_10b5_1NoRule 10b5-1 status of the transaction: 'under_plan' for sales scheduled in advance under a written plan, 'not_under_plan' for those the filing states were not, and 'not_stated' for filings that say nothing at all — which is every filing before the 2022 amendments and is a different claim from 'not_under_plan'. Omit to apply no filter of any kind.
window_daysNoTrailing window in days, ending today, used when no explicit date range is given. Accepts 1 to 3650; defaults to 365. Supplying start_date or end_date replaces it.
min_value_usdNoMinimum transacted value the filing itself stated, as a decimal string such as '250000' or '250000.50'. Rows the filing stated no per-share figure for are never matched by it: an absent figure is not zero, and a gift recorded without one would otherwise satisfy every threshold as a transaction that never happened.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries full behavioral burden and does so thoroughly. It discloses that totals count only open-market sales, that option exercises and tax withholdings are excluded, that share counts are as filed, that there is no market data feed or wealth estimate, and even explains Form 4/5 filing timing.

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 long but dense: it front-loads the core distinction and result shape, then adds behavioral caveats and routing hints. A few sentences like the Form 4/5 timing and pricing link are peripheral to invoking the tool, but they still serve transparency without bloating the essential message.

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 10 optional parameters, no annotations, and no output schema, the description fully covers what an agent needs: what the result contains, key exclusions, how to get more detail per person, and important data caveats. The rich per-parameter schema handles the remaining invocation details.

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 coverage is 100%, so the baseline is 3. The description adds high-level context that filters are 'the same as screen_insider_transactions' and that code filtering affects realized proceeds, but it does not substantially elaborate individual parameters beyond what the schema already says.

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 names a specific verb and resource ('screen insiders'), states the aggregation unit ('one row per person'), and defines the ranking metric ('cash they realized from open-market sales'). It also explicitly contrasts itself with screen_insider_transactions, so an agent can distinguish sibling tools immediately.

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?

The description is explicit about when to choose this tool: 'This is the tool for a question about people rather than trades' and contrasts it with returning transactions to aggregate yourself. It also mentions passing owner CIK to insider_profile, providing routing guidance beyond mere selection.

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