Skip to main content
Glama

Oxford Ledge

by com.oxfordledge
OverviewDiscussionsAdmin

Insider Cluster Scan

ol_insider_cluster_scan
Read-only

FLAGSHIP MOAT: scan for ACTIVE multi-insider cluster-buy/sell signals (distinct-actor Form 4 clusters with statistical strength). THREE GRAINS: pass tickers for a watchlist, a single ticker for that name's recent fired clusters, or NEITHER for the MARKET-WIDE scan (top fired clusters across every ticker, one row per ticker and direction). Returns {summary, count, events, grain, since_days, limit}; each event is {ticker, direction, insider_count, z_score, sector_z_score, percentile, window_start, window_end}. No fired clusters returns events=[] -- absence is not a signal; an unreachable store is REFUSED. Source: SEC EDGAR Form 4, windowed on FILING date so it is look-ahead-safe; FREE.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax events to return (default 25, hard cap 100; market-wide grain: default 10, max 25, more is refused).
tickerNoSingle ticker for its recent fired clusters (alternative to `tickers`). Omit BOTH for the market-wide scan.
tickersNoWatchlist of ticker symbols (e.g. ['AAPL','MSFT']). Max 100. Use this OR `ticker`, not both.
since_daysNoWindow in days: watchlist default 7 (max 365); market-wide default 30 (max 90; more is refused); not accepted with `ticker` (that grain has no window).
min_insider_countNoMinimum distinct insiders for a fired cluster (default 3).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / limit / description
      Previous value: -"Max events to return (default 25, hard cap 100; market-wide grain: default 10, clamped to 25)."New value: +"Max events to return (default 25, hard cap 100; market-wide grain: default 10, max 25, more is refused)."
    • changedInput schema / properties / since_days / description
      Previous value: -"Window in days: watchlist default 7 (max 365); market-wide default 30 (clamped to 90); ignored for the single-ticker grain."New value: +"Window in days: watchlist default 7 (max 365); market-wide default 30 (max 90; more is refused); not accepted with `ticker` (that grain has no window)."
    • changedInput schema / properties / tickers / description
      Previous value: -"Watchlist of ticker symbols (e.g. ['AAPL','MSFT']). Max 100. Use this OR `ticker`."New value: +"Watchlist of ticker symbols (e.g. ['AAPL','MSFT']). Max 100. Use this OR `ticker`, not both."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

ReadOnlyHint is set, so the bar is lower, yet the description adds real behavioral context: the exact return shape, empty-result semantics (events=[] means absence is not a signal), refusal on an unreachable store, and the SEC EDGAR Form 4 source windowed on FILING date for look-ahead safety. This is substantive disclosure beyond the annotation.

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?

Front-loaded with the core purpose and then organized under clear 'THREE GRAINS' and return-shape structure. Dense but nearly every clause carries information; the all-caps emphasis is stylistic noise but does not waste sentences.

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?

With no output schema, the description compensates by giving the top-level return object and each event's fields, plus the module's edge-case behavior. An agent has everything needed to call and interpret the tool 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 schema already documents all five parameters; the description still adds grain-level meaning (which params pair with which grain, plus refusal caps per grain). It goes beyond the schema without fully restating per-parameter syntax, so slightly above the 3 baseline.

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?

States a specific verb and resource: 'scan for ACTIVE multi-insider cluster-buy/sell signals (distinct-actor Form 4 clusters with statistical strength)'. This cleanly distinguishes it from siblings like ol_insider_recent_buys and get_insider_activity by naming the distinct concept of a multi-actor cluster with statistical strength.

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

Usage Guidelines5/5

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

Explicitly enumerates the three invocation modes (watchlist via `tickers`, single name via `ticker`, or neither for market-wide) and the constraints that select them. It also states exclusions ('not accepted with `ticker`') and semantic caveats ('absence is not a signal'), leaving little to inference.

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

All Oxford Ledge 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