Skip to main content
Glama

Insider Top Sellers

insider_top_sellers
Read-onlyIdempotent

Stock sales by a company's insiders and major holders, from SEC Form 4 — one seller at one company, every seller at one company, or the biggest sellers market-wide: "how many Amazon shares did Jeff Bezos sell in July", "insider selling at Apple this year", "which insiders sold the most stock recently", "largest insider sale last month". Pass issuer (ticker or company name) and owner (a person or a firm) to narrow it, since/until for the period, and group_by "owner" for one seller's total across several filings. Officers, directors and 10% owners file a Form 4 within two business days of every trade, so this gives the exact trade dates, shares, price per share and dollar value inside any month or week. Returns insider name and role, issuer and ticker, shares, price and dollar value. Counts only transaction code S, a sale at market; shares withheld for tax (F) are excluded, since those are a payroll mechanism rather than a decision to sell. Ranks over every row in the window — never a capped slice — and reports rows_considered so a cut is never silent. A price the filer states in another currency (e.g. Brazilian reais, in a footnote) is left out and counted in non_usd_rows_excluded, never ranked as dollars. A price that looks like a filer data-entry error is left out unless include_suspect is set, and a report filed as several parts counts as one filing. Sourced from SEC Forms 3/4/5.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many to return (default 20, max 100).
ownerNoLimit to one insider — name substring (e.g. "Berkshire") or SEC CIK.
sinceNoEarliest transaction date, ISO (YYYY-MM-DD).
untilNoLatest transaction date, ISO (YYYY-MM-DD).
issuerNoLimit to one issuer — ticker (e.g. "LEN") or SEC CIK. Substring match on issuer name also works.
group_byNoHow to roll transactions up before ranking. "filing" (default): sum every row on the same Form 4 into one total — a filing often reports one decision as several price-band lines, and a price-band row has no economic meaning on its own. A report filed as several documents for the same issuer, the same reporting owners and the same period of report, whose parts start on the same trade date (a long transaction table split across accessions), counts as one filing; accession_numbers lists every part. "row": rank individual transaction lines. "owner": sum every filing by the same insider against the same issuer across the whole window (e.g. several purchases over several days).
exclude_fundsNoDrop issuers that are funds reporting unitholders, not operating companies with real insiders (e.g. a BDC or interval fund). Best-effort name/security-type heuristic. Default false.
min_value_usdNoIgnore transactions below this dollar value.
include_suspectNoInclude transactions whose price looks like a filer data-entry error (see the caveat). Default false — suspect rows are excluded from rankings.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / exclude_funds
      Added value: +{
      +  "description": "Drop issuers that are funds reporting unitholders, not operating companies with real insiders (e.g. a BDC or interval fund). Best-effort name/security-type heuristic. Default false.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / group_by
      Added value: +{
      +  "description": "How to roll transactions up before ranking. \"filing\" (default): sum every row on the same Form 4 into one total — a filing often reports one decision as several price-band lines, and a price-band row has no economic meaning on its own. A report filed as several documents for the same issuer, the same reporting owners and the same period of report, whose parts start on the same trade date (a long transaction table split across accessions), counts as one filing; accession_numbers lists every part. \"row\": rank individual transaction lines. \"owner\": sum every filing by the same insider against the same issuer across the whole window (e.g. several purchases over several days).",
      +  "enum": [
      +    "row",
      +    "filing",
      +    "owner"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / include_suspect
      Added value: +{
      +  "description": "Include transactions whose price looks like a filer data-entry error (see the caveat). Default false — suspect rows are excluded from rankings.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / issuer
      Added value: +{
      +  "description": "Limit to one issuer — ticker (e.g. \"LEN\") or SEC CIK. Substring match on issuer name also works.",
      +  "type": "string"
      +}
    • changedInput schema / properties / min_value_usd / description
      Previous value: -"Ignore sales below this dollar value."New value: +"Ignore transactions below this dollar value."
    • addedInput schema / properties / owner
      Added value: +{
      +  "description": "Limit to one insider — name substring (e.g. \"Berkshire\") or SEC CIK.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

With annotations covering the safety profile, the description still adds substantial behavioral detail: only code S is counted, code F tax withholding is excluded and why, rankings run over every row in the window with rows_considered reported so truncation is never silent, non-USD prices are excluded and counted in non_usd_rows_excluded, and multi-part filings are collapsed into one. These are non-obvious traits an agent could not infer from annotations.

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?

Purpose is front-loaded in the first clause, and the example queries earn their place by illustrating scope combinations. The single dense paragraph runs long and bundles several distinct caveats together, which slightly hurts scanability.

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 a 9-parameter, all-optional analytics tool with no output schema, the description covers return fields (insider name and role, issuer, ticker, shares, price, dollar value), ranking guarantees, exclusion accounting, and data provenance (SEC Forms 3/4/5). Nothing material is missing for correct invocation.

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% and the group_by enum description already explains filing/row/owner rollup in depth, so the description largely restates it ("group_by 'owner' for one seller's total across several filings"). It adds only marginal framing beyond the schema, which is the baseline 3 case.

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 (insider stock sales from SEC Form 4) and enumerates the three scope modes: one seller at one company, every seller at one company, or market-wide leaders. The contrast with the sibling insider_top_buyers is implicit but unambiguous, since the description repeatedly frames everything as sales and names the only included transaction code (S).

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?

Gives four concrete natural-language query patterns ("how many Amazon shares did Jeff Bezos sell in July", "which insiders sold the most recently") and maps them to the parameters that select them (issuer, owner, since/until, group_by). It does not explicitly name insider_top_buyers as the alternative for purchases or state when-not-to-use, which keeps it below a 5.

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.