AlphAI

Insider cluster buys

alphai_insider_clusters

Read-onlyIdempotent

Find issuers where several different insiders bought on the open market in one run of purchases (SEC Form 4, purchase dates chained while at most 10 days apart, an episode capped at 30 days). Every purchase is examined before a buyer counts: an IPO or PIPE allocation — by its price shape or by the filing's own footnote saying the shares came from the issuer, an offering or a negotiated block (buyer reason: placement, offering, private) — ESPP / DRIP / director-plan lots, units and note exchanges without a price, and the same transaction reported through two owners are labeled per buyer (role: independent, plan_like, unpriced, duplicate_of) and hidden from the default open_market list; ask pattern=plan_or_offering, holders_only or all to see them. buyers counts independent buyers, buyers_total everyone who bought. days is measured on known_at, the moment the episode's latest filing reached EDGAR, so 'what became known this month' is one call; a Free account reaches 30 days, Basic and Pro 90. Sort recent (default, newest known first), buyers or value; follow next_cursor with the same sort. Each result links every filing (accession number, EDGAR URL) and the news uids to open with alphai_article. Descriptive screen, not point-in-time and not a return forecast; coverage starts at meta.coverage_since (the table begins in August 2025).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "alphai_insider_clusters"
  }
}

Input Schema

Name	Required	Description	Default
`days`	No	Lookback in days over known_at (latest filing); default 30.
`sort`	No	recent = newest known first.	recent
`limit`	No	Rows per page, default 10; above 20 needs Pro.
`cursor`	No	Opaque next_cursor, unchanged.
`symbol`	No	One ticker; former names and share-class siblings match too. Empty for the whole market.
`min_usd`	No	Drop episodes whose known total is below this many dollars.
`pattern`	No	Which verdicts to return; open_market by default.	open_market
`min_buyers`	No	Minimum independent buyers for open_market rows (everyone who bought for plan rows).

Output Schema

Name	Required	Description	Default
`meta`	Yes
`results`	No
`next_cursor`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 26, 2026

addedOutput schema / properties / results / items / properties / buyers_detail / items / properties / reason

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "placement",
+        "offering",
+        "private"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

AddedSep 22, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already cover readOnly/non-destructive/idempotent, and the description adds substantial behavioral context: buyer-role labeling (independent/plan_like/unpriced/duplicate_of), which records are hidden by default and how to reveal them, the known_at measurement basis, coverage_since, and pagination via next_cursor. This is rich, non-redundant disclosure.

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

Conciseness3/5

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

Purpose is front-loaded, but the body is one dense paragraph cramming exclusion rules, counting semantics, tier limits, sorting, and disclaimer into a stream that is hard to parse. The content largely earns its place, but the structure could be broken up for readability.

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?

Given an output schema exists (so return shape needn't be explained), the description still covers the critical operational facts: coverage start, account-tier reach, pagination, exclusion defaults, and result links to filings/news uids. An agent has everything needed to call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: buyers counts independent buyers vs buyers_total counting everyone, days measured on known_at, and min_buyers behaving differently for plan rows. It augments the enum/param docs rather than restating them.

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 states a precise verb+resource+scope: issuers where multiple distinct insiders made open-market purchases within a chained episode, with the mechanical definition (<=10 days apart, 30-day cap, SEC Form 4). It clearly signals it is a descriptive screen, not point-in-time or forecast, though it doesn't explicitly name a sibling tool to contrast with.

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?

It gives clear usage context: 'what became known this month is one call' via the days/known_at semantics, guidance on when to switch to pattern=plan_or_offering/holders_only/all, and tier limits (Free 30, Basic/Pro 90). It stops short of naming alternative tools or explicit when-not-to-use-this conditions beyond the 'not point-in-time' caveat.

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

All AlphAI 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.