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).

Input Schema

TableJSON 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

TableJSON 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.7/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses substantial behavior: how purchases are classified and hidden by default, that buyers counts only independent buyers, that days is measured on known_at, account-tier limits on lookback, and that the table starts in August 2025. This is exactly the kind of non-obvious behavior an agent needs to interpret results correctly.

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 description is dense and front-loaded with the core purpose, and every sentence contributes meaningful detail. However, it is delivered as one long paragraph with many embedded clauses; breaking it into a few shorter blocks or bullets would make it easier to parse without losing information.

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 the tool's complexity, eight parameters, and existing output schema, the description is remarkably complete. It covers the classification rules, default behavior, pagination with sort consistency, account limitations, links to filings and news uids, and the coverage start date. There are no obvious gaps an agent would need to fill by trial and error.

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 the schema already has 100% parameter description coverage, the tool description adds deeper meaning: it explains what each pattern value returns, clarifies that min_buyers counts independent buyers for open_market but everyone for plan rows, and discusses account-tier differences for days and limit. This goes well beyond the baseline expected when schema descriptions are already strong.

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 a precise verb and resource: 'Find issuers where several different insiders bought on the open market in one run of purchases.' It further specifies the SEC Form 4 basis, date-chaining rules, and episode cap, making it clearly distinct from sibling tools like alphai_insider_news or alphai_tickers.

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 strong contextual cues: 'what became known this month is one call', and explicitly states the tool is 'Descriptive screen, not point-in-time and not a return forecast', which sets expectations for appropriate use. It does not name alternative sibling tools for comparison, so it falls short of fully explicit routing guidance.

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.