Skip to main content
Glama

Search insider trades

get_insider_trades
Read-onlyIdempotent

Search normalized insider transactions from SEC Forms 3/4/5 (US public companies). Returns rows with pre-computed value_usd and a quote-ready summary string with the SEC filing link. footnote_level says where a row's footnotes live: transaction - in the row's footnotes; filing - not linked to the row yet, the filing's footnotes are in filing_footnotes once per accession.

Input Schema

NameRequiredDescriptionDefault
limitNoMax rows per page, default 50, cap 500.
sinceNoEarliest transaction date, YYYY-MM-DD.
untilNoLatest transaction date, YYYY-MM-DD.
cursorNoOpaque pagination token from the previous response's page.next_cursor; pass it back verbatim to fetch the next page.
insiderNoSubstring match on the insider's name, e.g. "MUSK".
tickersNoTicker symbols to include, e.g. ["NVDA","AAPL"]. Empty = all issuers.
txn_typeNobuy (open-market buy: code P, acquisition, not derivative, price above zero, not offset in the same filing by the same shares at the same price), sell (S), grant (A), exercise (M/X), or gift (G). Omit for all.
txn_codesNoSEC transaction codes as filed, matched exactly, e.g. ["K"] for equity swaps and hedges, ["J"] for other acquisitions or dispositions. With txn_type both must hold. Omit for all.
equity_swapNotrue = only transactions the filer flagged equitySwapInvolved, whatever their code.
relationshipNoFilter by insider role.
min_value_usdNoMinimum transaction value in USD (shares x price).
exclude_10b5_1NoDrop pre-scheduled 10b5-1 plan transactions; true (default) for signal-seeking, false for full audit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / txn_type / description
      Previous value: -"buy (open-market/private purchase P), sell (S), grant (A), exercise (M/X), or gift (G). Omit for all."New value: +"buy (open-market buy: code P, acquisition, not derivative, price above zero, not offset in the same filing by the same shares at the same price), sell (S), grant (A), exercise (M/X), or gift (G). Omit for all."
  2. Changed2 schema fields changed
    • addedInput schema / properties / equity_swap
      Added value: +{
      +  "default": false,
      +  "description": "true = only transactions the filer flagged equitySwapInvolved, whatever their code.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / txn_codes
      Added value: +{
      +  "description": "SEC transaction codes as filed, matched exactly, e.g. [\"K\"] for equity swaps and hedges, [\"J\"] for other acquisitions or dispositions. With txn_type both must hold. Omit for all.",
      +  "items": {
      +    "enum": [
      +      "P",
      +      "S",
      +      "V",
      +      "A",
      +      "D",
      +      "F",
      +      "I",
      +      "M",
      +      "C",
      +      "E",
      +      "H",
      +      "O",
      +      "X",
      +      "G",
      +      "L",
      +      "W",
      +      "Z",
      +      "J",
      +      "K",
      +      "U"
      +    ],
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  3. Changed4 schema fields changed
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / exclude_10b5_1 / default
      Added value: +true
    • addedInput schema / properties / limit / default
      Added value: +50
  4. Added

TDQS

A3.5/5.0
Behavior4/5

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

Annotations cover safety (readOnlyHint, idempotentHint), and the description goes further by disclosing the return shape: value_usd is pre-computed and summary is quote-ready with the filing link. The footnote_level explanation ('transaction' vs 'filing') is genuinely useful behavioral context that exists nowhere else since there is no output schema.

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?

Front-loaded with the core purpose in the first clause, then return-value context, then the footnote semantics. Three sentences with no filler. The final footnote_level sentence is dense and slightly harder to parse but earns its place given no output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter search tool with full schema coverage and no output schema, the description covers the operation, key derived return fields, and a non-obvious response field's semantics. It omits pagination behavior and a fuller return-shape description, but is adequate overall.

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 documents all 12 parameters including the non-obvious txn_type/txn_codes interaction and the exclude_10b5_1 default. The description adds essentially no parameter meaning beyond that, which is the correct baseline when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Search normalized insider transactions from SEC Forms 3/4/5 (US public companies)'. This is clearly the raw-filing search tool in a cluster of derived-analysis siblings (cluster_buys, planned_vs_executed, trades_before_events), but the description never names those siblings to make the boundary explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use or when-not-to-use guidance is provided. With ten siblings including several that analyze the same underlying trades (trades_before_events, cluster_buys, get_planned_sales), the description gives an agent nothing to route on beyond the operation name.

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