Fresh SEC Form 4 insider trades: filter by ticker, insider, buy/sell and value; cluster buys.
Scored across 3 tools
cluster_buys and insider_trades both draw from the same Form 4 feed, which creates some overlap since a cluster is essentially a filtered view of trades. However, cluster_buys is clearly scoped to multi-insider buying patterns while insider_trades is the raw latest-transactions feed, and data_status is distinct metadata, so an agent can mostly tell them apart.
All three names use consistent snake_case noun_phrase conventions (cluster_buys, data_status, insider_trades). The style is predictable and readable across the set.
Three tools is well-scoped for a focused insider-filing monitoring server: raw trades, aggregated clusters, and data freshness each earn their place. It is slightly lean but not thin, since each covers a genuinely different need.
The surface covers recent trades, cluster detection, and data freshness, which are the core workflows for this domain. Minor gaps exist, such as no explicit per-ticker or per-insider lookup/history tool, but agents can work around this via the adjustable filters on the existing tools.
Companies where 2+ different insiders bought the stock on the open market within 7 days (window, minimum insiders and minimum dollars adjustable), with each insider, total dollars and filing links.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look back N days of filings (1-45) | |
| limit | No | Clusters (1-100) | |
| ticker | No | Only these tickers (comma separated) | |
| window | No | Buys must fall within this many days of each other (1-30) | |
| minValue | No | Only clusters whose buys add up to at least this many US dollars | |
| minInsiders | No | Distinct insiders buying (2-10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a read-only, idempotent, non-destructive, open-world query, so the safety profile is covered. The description adds real behavioral context beyond that: it defines what constitutes a cluster (2+ distinct insiders, 7-day window, open-market buys) and states which values are adjustable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the core cluster definition and appends the output contents. It is efficient, though the parenthetical about adjustable knobs is slightly compressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully names the return contents (each insider, total dollars, filing links), and all six optional parameters are fully documented in the schema. An agent has enough to invoke it correctly; missing only explicit sibling routing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter already carries its own range, default, and meaning. The description only reiterates that window, minInsiders, and minValue are adjustable, adding no syntax or interpretation beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise screening rule: companies where 2+ distinct insiders bought on the open market within a 7-day window. That verb+resource+criteria combination clearly distinguishes it from the broad insider_trades sibling, though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance, and no mention of the alternative insider_trades tool for non-clustered lookups. The criteria imply a use case but the agent must infer it from the description's semantics alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When Insidewell last pulled new Form 4 filings from EDGAR and which filed dates it covers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral fact that it reports both a pull timestamp and a covered-date range, but discloses nothing further about latency, update cadence, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, immediately conveying both halves of the returned information. Nothing to trim and nothing buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-argument status tool with no output schema, the description adequately explains what comes back (last pull time and covered filed dates). It could be stronger by noting the intended use as a liveness/coverage precheck, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there is no parameter semantics to explain; the baseline for a 0-parameter tool applies. Nothing in the description misrepresents the (empty) input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description concretely states what the tool reports: the last pull time of Form 4 filings from EDGAR and the covered filed dates. That is a specific resource+content statement, not a tautology of the name. It does not, however, explicitly contrast itself with the sibling data tools (cluster_buys, insider_trades).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus cluster_buys or insider_trades, nor any precondition (e.g. 'call before querying insider_trades to confirm coverage'). Usage must be inferred entirely from the tool name and the freshness framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest insider transactions from SEC Form 4 filings (EDGAR, refreshed about once a minute), newest filed first, up to 100 rows: ticker, insider, role, code (P buy, S sale, ...), shares, price, dollar value, dates and the filing link. Defaults to open-market buys and sales filed in the last 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Trade date to (YYYY-MM-DD) | |
| code | No | Transaction codes: P = open-market buy, S = sale (default P,S); also A (grant), M (option exercise), F (tax withholding), G (gift) ... or all | P,S |
| days | No | Filed in the last N days when no from date is given (1-45) | |
| from | No | Trade date from (YYYY-MM-DD) | |
| plan | No | Rule 10b5-1 trading plans: exclude (only discretionary trades) or only | |
| role | No | director, officer or ten_percent_owner | |
| limit | No | Rows (1-100) | |
| offset | No | Skip rows (paging, up to 2000) | |
| ticker | No | One ticker or up to 25, comma separated (e.g. NVDA,AAPL). Empty = every company | |
| insider | No | Insider name (part of it, e.g. musk) or their SEC CIK number | |
| minValue | No | Only trades worth at least this many US dollars (shares × price) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/openWorld, so the bar is lower. The description adds genuine operational context beyond them: ~once-per-minute refresh cadence, newest-filed-first ordering, and a 100-row ceiling. It stops short of documenting rate limits or pagination behavior in depth, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose and data source, then packs the field list and defaults efficiently into essentially two sentences. The mid-sentence return-field enumeration is long but informative rather than wasted; slightly dense but well organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates returned fields, plus cadence, ordering, row cap, and default filters. For an 11-parameter read tool with full schema coverage this is close to complete; only paging depth and sibling routing are left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 11 parameters including code meanings, ranges and defaults. The description only restates the default code set (P,S) and 7-day window, adding no syntax or semantics beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (SEC Form 4 insider transactions from EDGAR) with a clear verb (list/latest) and enumerates the returned fields. This is readily distinguishable from siblings like cluster_buys (aggregated signal) and data_status (system status). An agent knows exactly what it retrieves 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its defaults ('open-market buys and sales filed in the last 7 days') but never states when to choose this over cluster_buys or data_status, nor any when-not conditions. Guidance is inferable from defaults, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cluster_buysdata_statusinsider_tradesInsidewell: SEC Form 4 insider buys/sells by ticker or whole market, with cluster-buy alerts.
Insidewell: SEC Form 4 insider buys/sells by ticker or whole market, with cluster-buy alerts.
Filing-verified U.S. insider-buy signals from SEC Form 4: cluster buys and large-vs-holdings buys.
US insider trades, 13F holdings, 13D/13G, Form 144 and politicians' stock trades. Free, no API key.
Add one secure layer between your agents and this server.