Skip to main content
Glama

Form4API — SEC Insider Trading

explain_signal

Read-only

Explain why a signal fired: the insiders and trades counted, what was excluded, and the criteria (Business plan+). Use this when the question is WHY a named company's signal fired, or WHICH insiders and trades made up its cluster. It takes the ticker directly, so there is no need to call GET /v1/signals first; that endpoint is for finding which companies have signals. Reconstructs the full evidence behind one company's insider signal from GET /v1/signals: the detection criteria (5-day cluster window, 3-insider threshold, 90-day ratio window, 10b5-1 and derivative-row exclusion), the list of cluster buyers and sellers (each with their role and individual trades in the window), trades that were excluded from the cluster count and why (10b5-1 plan, derivative security, or superseded by amendment), and the raw buy/sell share totals behind the 90-day ratio. Use this to audit or debug a specific signal rather than to scan many companies (use GET /v1/signals for that). This is a LIVE reconstruction from current non-superseded data, computed on every request (no caching) — it can differ slightly from the originally stored signal if trades were amended afterward. Requires Business plan or higher (402 PLAN_REQUIRED on Free/Starter/Pro). Returns 404 COMPANY_NOT_FOUND if the ticker isn't tracked, 404 SIGNAL_NOT_FOUND if no signal exists for the given/most-recent date, or 400 INVALID_DATE if date isn't YYYY-MM-DD.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ticker": "<ticker>"
    },
    "name": "explain_signal"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoExact signal date to explain, format YYYY-MM-DD. Omit to explain the company's most recent signal. Returns 404 SIGNAL_NOT_FOUND if no signal exists for the given (or most recent) date.
tickerYesCompany ticker symbol, case-insensitive (e.g. "AAPL").

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations: discloses that the result is a LIVE non-cached reconstruction recomputed per request that may drift from the originally stored signal after amendments. It also states the plan gate (Business+, 402 PLAN_REQUIRED) and the concrete error surface (404 COMPANY_NOT_FOUND, 404 SIGNAL_NOT_FOUND, 400 INVALID_DATE), which no structured field provides.

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?

Front-loaded and information-dense, but the scan-vs-audit guidance is stated twice ('that endpoint is for finding which companies have signals' and later 'use GET /v1/signals for that'), and the criteria list overlaps with the audit/debug sentence. The content is valuable but the paragraph is longer than necessary and could be tightened without losing meaning.

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 read-only, two-parameter tool with no output schema, the description covers what is returned (criteria, cluster buyers/sellers with roles and trades, exclusions and reasons, raw buy/sell totals), how it is computed, access tier, and every failure mode. Nothing an agent needs to call it correctly or interpret the result is missing.

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 adds workflow meaning: the ticker is accepted directly without a prior lookup, and omitting `date` explains the most recent signal (with the SIGNAL_NOT_FOUND consequence restated in context). It does not add format or syntax detail beyond the schema, keeping it just above 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 — 'Explain why a signal fired' — and immediately enumerates the output content (insiders and trades counted, exclusions, criteria). It explicitly distinguishes itself from GET /v1/signals, so an agent can route between explain-a-signal and find-signals without opening either schema.

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?

Gives an explicit trigger ('when the question is WHY a named company's signal fired, or WHICH insiders and trades made up its cluster'), an explicit non-trigger ('rather than to scan many companies'), and names the alternative endpoint for the other case. It also clarifies that the ticker can be passed directly, removing a prerequisite call the agent might otherwise assume is required.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.