Insider Trading

Insider Trades

insider_trades

Read-onlyIdempotent

SEC Form 4 insider transaction filings for a US-listed company: filing date, the officer/director/10%-owner who filed, whether the filing was made under a Rule 10b5-1 trading plan (rule_10b5_1_plan true/false, null when the filing predates the April 2023 checkbox; plus the plan adoption date and footnote text when stated), and a link to the filing on EDGAR. Answers who at a company has been buying or selling its stock recently. Ticker or company name is resolved to a CIK, so results are that issuer's filings. Response field matched_by says whether the company was matched by ticker or by company name.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "days": 30,
      "ticker": "NVDA"
    },
    "name": "insider_trades"
  }
}

Input Schema

Name	Required	Description
`days`	No	Look back period in days (default: 365)
`limit`	No	Max filings to return (default: 20, max 200)
`ticker`	Yes	Stock ticker ("AAPL", "NVDA"), company name ("NVIDIA Corp"), or CIK
`plan_flags`	No	How many of the newest filings to read for the Rule 10b5-1 plan flag (one SEC request each; default 5, max 25, 0 to skip). Older rows carry plan_flag_status "not_fetched".

Output Schema

Name	Required	Description
`cik`	No	SEC CIK the ticker resolved to (unpadded)
`period`	Yes	Look back period description
`ticker`	Yes	Stock ticker in uppercase
`filings`	Yes
`truncated`	No	True when more filings matched upstream than were returned; raise `limit` to see them
`matched_by`	No	How the company was matched: ticker, cik or company_name
`company_name`	No	Canonical SEC registrant name
`total_form4_filings`	Yes	Number of Form 4 filings RETURNED in `filings` — always equals filings.length
`matched_form4_filings`	No	Number of Form 4 filings matching upstream for this company and window, which may exceed the number returned

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 15, 2026

addedOutput schema / properties / matched_by

Added value: +{
+  "description": "How the company was matched: ticker, cik or company_name",
+  "type": "string"
+}

Changed5 schema fields changedNov 15, 2026

addedInput schema / properties / plan_flags

Added value: +{
+  "description": "How many of the newest filings to read for the Rule 10b5-1 plan flag (one SEC request each; default 5, max 25, 0 to skip). Older rows carry plan_flag_status \"not_fetched\".",
+  "type": "number"
+}

addedOutput schema / properties / filings / items / properties / plan_adoption_date

Added value: +{
+  "description": "Plan adoption date (YYYY-MM-DD) parsed from the filer's footnote, when stated",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / filings / items / properties / plan_flag_status

Added value: +{
+  "description": "read = flag taken from the filing; predates_field = filing has no checkbox; unavailable = document could not be read; not_fetched = beyond the plan_flags window",
+  "enum": [
+    "read",
+    "predates_field",
+    "unavailable",
+    "not_fetched"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / filings / items / properties / plan_footnotes

Added value: +{
+  "description": "Footnote texts in the filing that mention Rule 10b5-1",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / filings / items / properties / rule_10b5_1_plan

Added value: +{
+  "description": "Rule 10b5-1 trading-plan checkbox on the Form 4: true = ticked, false = explicitly unticked, null = filing predates the field (before April 2023), not fetched or unreadable; see plan_flag_status",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

First observedSep 23, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description goes further: it discloses that identifiers are resolved to a CIK, that the `rule_10b5_1_plan` value is null for filings predating the April 2023 checkbox, and that each plan-flag lookup costs one SEC request while older rows are marked 'not_fetched'. That is real behavioral context beyond structured fields; it stops short of describing failure behavior for unresolvable tickers.

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 core purpose is front-loaded and the sentence order is logical: what is returned, then the question it answers, then identifier resolution. It is dense — the long parenthetical on the plan flag is heavy — but no sentence is 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?

For a four-parameter read tool with an output schema, everything an agent needs is present: what the records are, how identifiers resolve, the plan-flag nuance including the null semantics, and how the response's `matched_by` should be read. Nothing essential is left to inference.

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 schema already documents all four parameters and their defaults, making a 3 the baseline. The description adds some meaning beyond the schema — ticker/company name/CIK resolution to an issuer CIK and the `matched_by` response field — but it does not explain how `plan_flags` affects cost or result shape beyond what the schema's own description 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?

States a specific verb and resource — SEC Form 4 insider transaction filings for a US-listed company — and enumerates what each filing contains (filing date, filer role, plan flag, EDGAR link). It also states the question the tool answers ('who at a company has been buying or selling its stock recently'), which lets an agent distinguish it from insider_13d or insider_8k without opening the schema.

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?

The 'answers who has been buying or selling recently' framing gives an agent a clear context for when this tool fits, and the required ticker parameter makes the precondition obvious. However, it never names the sibling tools it should be preferred over or notes when to use insider_13d / insider_8k instead, so no exclusions are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Insider Trading tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.