Skip to main content
Glama

Livermore

by io.github.AAAZZZR
OverviewDiscussionsAdmin

Insider trades (Form 4)

get_insider_trades
Read-onlyIdempotent

Insider transactions from SEC Form 4 filings (coverage starts July 2021; updated daily). One row per filing and transaction type: same-day lots are combined, avg_price_usd is value-weighted, value_usd is the USD total, shares_owned_after is the holding after the last lot, ownership_change_pct is the change in the insider's holding in percent (null = new position or not computable). Filter by ticker, insider_cik, filing-date range, codes, the primary insider's role and minimum value. Without ticker or insider_cik the query is market-wide and limited to 30 days of filings (default: last 7 days). Codes: P = open-market or private purchase, S = sale, A = grant or award, D = disposition to the issuer, F = shares withheld for taxes, G = gift, M = option exercise under a company plan, X = in-the-money exercise, C = conversion, W = inheritance, J = other. Default codes P and S. Dates are YYYY-MM-DD; filed_at is ISO 8601 UTC and filed_date its US Eastern date; backfilled filings may only have the date (filed_at at midnight Eastern). price_outlier is true when the reported price or value is not reliable (a typo, a wrong unit or a foreign company's home-market shares priced in local currency instead of US dollars); avg_price_usd and value_usd are then as filed, and the site leaves these rows out of rankings and totals. rule_10b5_1 is null for filings before 2023. Each row links to livermore.club (url) and the SEC filing (sec_url). At most 200 rows per call; use page for more.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoLatest SEC filing date, YYYY-MM-DD, inclusive.
fromNoEarliest SEC filing date, YYYY-MM-DD (US Eastern).
pageNoPage number starting at 1; each page has `limit` rows. Check has_more.
sortNofiled = newest filing first (default); trade_date = most recent trade date first; value = largest USD value first (rows flagged as price outliers or duplicate filings are left out).filed
codesNoForm 4 transaction codes to include, e.g. ["P"] for purchases only, or "all". Default ["P","S"] (open-market purchases and sales).
limitNoMaximum rows to return (1-200, default 25).
rolesNoKeep rows whose primary reporting owner has any of these roles: ceo, cfo, director, officer, owner10 (10% owner). Empty = any role.
tickerNoOnly this company's filings (all share classes of the issuer), e.g. AAPL or BRK.B.
insider_cikNoOnly filings on which this insider (reporting owner) appears, across all companies. Get the CIK from search.
min_value_usdNoMinimum transaction value in USD (rows without a price are then excluded).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
noteYes
pageYes
rowsYes
limitYes
scopeYes
stockYes
filtersYes
insiderYes
has_moreYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark the tool as read-only and idempotent, and the description adds substantial behavior: row consolidation semantics, value weighting, price outlier handling, backfilled filing date caveats, rule_10b5_1 null behavior, URL fields, and a 200-row pagination cap. This is far beyond the annotation baseline.

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

Conciseness5/5

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

The description is long but densely packed and front-loaded with the core purpose, then row semantics, constraints, codes, dates, outliers, and pagination. Each clause earns its place and no words are wasted.

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 10-parameter, 0-required tool with an output schema, the description is unusually complete: it covers defaults, edge cases, date/timezone details, code meanings, outlier flags, pagination, and returned fields. An agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema description coverage is 100%, the description enriches every parameter group: it explains the meaning of transaction codes, the date format and timezone handling, the scope of ticker and insider_cik filters, and the impact of min_value_usd. This adds real selection value 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 opens with 'Insider transactions from SEC Form 4 filings,' naming a specific verb, resource, and data source. It clearly differentiates from sibling tools like get_stock and get_insider_lists by focusing on Form 4 filing transactions.

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 description gives concrete usage context: it explains market-wide queries require a 30-day window, defaults to 7 days, and defaults to P/S codes. It doesn't explicitly name alternative tools, but the operational guidance is clear enough for an agent to decide when to call this endpoint.

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

All Livermore toolsInspect
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.

Resources