Skip to main content
Glama

KeyVex

get_planned_insider_sales

Read-only

A ticker search also returns rows this issuer FILED UNDER SYMBOLS IT NO LONGER LISTS (renames, filer typos, ADR spellings). Each row keeps ticker as SEC received it and gains current_ticker when the issuer trades under a different symbol today. Separately-listed share classes are NOT merged, and asking for a RETIRED symbol returns only rows filed under it — retired symbols get reissued to other companies. Returns Form 144 filings — notices of proposed sale by corporate insiders (officers, directors, 10%+ holders) under Rule 144 of the Securities Act. Each record is one planned-sale line from one filing. ⚠ aggregate_market_value is NULLABLE. A Form 144 that did not state a value now reports null rather than 0 — but a filer who genuinely stated 0.00 still reports 0, and that happens. Null never satisfies min_value and sorts last. ⚠ AND SOME FILERS STATE THE ISSUER'S MARKET CAP IN THAT BOX, WHICH PUTS THEM AT THE TOP OF A DESCENDING VALUE SORT. Measured 2026-09-04: 5 of the top 100 — SYF 4,000 shares stating $25.24bn ($6.31m per share), IT 860 shares stating $11.72bn. Dividing those by shares_outstanding on the same row gives $77.57 and $185.66, which are the real share prices. ⚠ THE CHECK CATCHES TWO OF THOSE FIVE, NOT ALL FIVE, AND SAYS SO RATHER THAN OVERSTATING ITSELF. TCMD, EPSM and XHR imply $36,017, $17,577 and $16,686 per share — absurd for those issuers, but below BRK.A's real $740,000 peak, so no per-row test separates them from a genuine high-priced sale. They still read 'checked'. Settling them needs a comparison against the day's actual price bar. Every row therefore carries aggregate_market_value_check: 'checked' the value implies a plausible price for the shares sold 'not_stated' no value was filed (distinct from a filed 0.00) 'no_share_count' no share count, so the check could not run 'implausible_looks_like_market_cap' implies a per-share price above any that has traded, and shares_outstanding yields a plausible one instead 'implausible_unexplained' implies an impossible price and shares_outstanding does not explain it — we can say it is not the sale value without being able to say what it is ⚠ The number is NOT corrected. SEC's bytes are served exactly as filed, and we do not invent a value the filer never stated. If you rank by this field, exclude anything whose check does not read 'checked' — otherwise the top of your list is market capitalisations. Use this when the user asks about: insiders who have announced they're about to sell, upcoming insider sales at a specific company, large planned sales by value, or which executives are signaling intent to exit positions. Form 144 is a forward-looking signal. It's filed BEFORE the actual sale, which later lands as a Form 4. The complement to get_insider_transactions: that tool tells you what insiders just did, this one tells you what they're about to do. Filing thresholds: ≥5,000 shares OR ≥$50,000 aggregate value. The aggregate_market_value is the insider's estimate at filing time; the actual sale price/value can differ. The approximate_sale_date is also an estimate — the real Form 4 transaction_date may be days later. Most Form 144 filings list one security line, but a single filing can cover multiple share classes (e.g., separate Class A + Class B). Each line is returned as its own record.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum records to return. Default 50, max 500.
sinceNoISO date (YYYY-MM-DD). Only records on or after this date, using sort_by as the date field.
untilNoISO date (YYYY-MM-DD). Only records on or before this date.
tickerNoStock symbol filter, e.g. 'AAPL'. Case-insensitive.
sort_byNoField used for ordering and for the since/until date filters. Default: filing_date.
min_valueNoFilter to filings with aggregate_market_value >= this amount (USD). Use to focus on large planned sales.
filer_nameNoFull or partial filer name; case-insensitive substring match. Example: 'Cook' matches Tim Cook's filings. NOTE: plain substring (not word-boundary) match — a short surname can match mid-word too (e.g. 'Huang' also matches 'CHUANG'). Pass a longer/fuller name to disambiguate a specific person.
sort_orderNoDefault: desc (most recent / largest first).
company_cikNoSEC CIK number (10-digit, padded with leading zeros). Alternative to ticker when known.

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 cover only the safety profile (readOnly/destructive/openWorld), so the description carries the real behavioral burden and does it well: it discloses that aggregate_market_value is nullable and that null differs from a filed 0.00, that nulls never satisfy min_value and sort last, that filers sometimes place issuer market cap in that box (with measured evidence), that the value is never corrected, and the exact semantics of every aggregate_market_value_check value including its known blind spot. It also discloses ticker-rename/retired-symbol filtering behavior and the multi-share-class row expansion. This is a rare case of a description disclosing failure modes rather than only the happy path.

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

Conciseness3/5

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

Every paragraph carries real information, but the document is roughly 600 words with heavy ⚠/CAPS formatting and repetition — the market-cap-in-the-value-box problem is explained, then re-explained with per-ticker detail, then restated in the check-value definitions. More importantly it is not front-loaded: the actual purpose (Form 144 filings) appears only after a long ticker-caveat opening, so an agent skimming the first lines gets a symbol-rename warning instead of what the tool returns.

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?

There is no output schema, so the description must explain the returned shape and it does: each record is one planned-sale line, rows carry ticker as received plus current_ticker when the issuer has renamed, and every row carries aggregate_market_value_check with its enumerated meanings. It also flags the estimate nature of both aggregate_market_value and approximate_sale_date and their divergence from the later Form 4. For a 9-parameter, no-output-schema read tool this is as complete as an agent could need.

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?

Schema coverage is 100%, so baseline is 3, but the description adds genuine semantics the schema lacks: min_value interacts with NULLs ('Null never satisfies min_value and sorts last'), and ticker matching returns rows filed under former symbols and carries current_ticker, while querying a retired symbol returns only rows filed under it. It also warns that sort_by=aggregate_market_value needs the check field filtered to 'checked'. The remaining parameters (limit, since/until, filer_name, company_cik) get no added meaning beyond the schema.

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: 'Returns Form 144 filings — notices of proposed sale by corporate insiders ... under Rule 144'. It explicitly contrasts itself with the closest sibling, get_insider_transactions ('that tool tells you what insiders just did, this one tells you what they're about to do'), so an agent can route between the two without opening either schema. The only weakness is placement — the purpose sentence sits behind a long ticker-semantics preamble — but the content itself is unambiguous.

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 enumerates concrete triggering intents: 'insiders who have announced they're about to sell, upcoming insider sales at a specific company, large planned sales by value, or which executives are signaling intent to exit positions.' It names the alternative tool and the condition that selects it (forward-looking Form 144 vs. completed Form 4), and notes the filing thresholds (≥5,000 shares OR ≥$50,000) that bound when this data even exists. Nothing relevant is left to inference.

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