Skip to main content
Glama

SEC Form 4 insider trades

insider_trades

Retrieve SEC Form 4 insider transactions by ticker or latest market-wide, with names, titles, codes, shares, prices, values, dates; filter purchases (P) or sales (S).

Instructions

Insider transactions from SEC Form 4: insider name and title, transaction code, shares, price, value, date. History for a ticker or the latest trades across companies (type P for open-market purchases, S for sales).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoP purchases, S sales (latest view only)
tickerNoUS ticker symbol, e.g. GME. Class shares as on the SEC list, e.g. BRK-B.
windowNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral load. It usefully discloses the return content and the scope difference between ticker-history and cross-company views, but says nothing about limits, freshness, rate limits, or what happens with no parameters supplied.

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?

Two sentences, front-loaded with the resource and payload, with no filler. The field enumeration is slightly list-like but still earns its place by telling the agent what comes back.

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

Completeness3/5

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

For a 3-parameter read tool with no output schema, the description adequately covers the returned fields and the two query modes. It is incomplete on the window parameter and on behavioral constraints, and with no annotations the safety/limits picture is thin.

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 67%; the description echoes the P/S meaning (also in the schema) and hints that 'history for a ticker' is a mode, but the window enum (7d/30d/90d) is neither described in the schema nor explained here, leaving a real gap.

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?

The description names a specific resource ('Insider transactions from SEC Form 4') and enumerates the returned fields, so an agent immediately knows what it fetches. It does not, however, distinguish itself from the close sibling planned_insider_sales, which is a distinct insider-activity tool.

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

Usage Guidelines3/5

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

It implies two usage modes ('History for a ticker or the latest trades across companies') and explains the P/S filter, giving the agent operational context. It offers no explicit when-to-use/when-not guidance and never references an alternative tool for related insider data.

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