Skip to main content
Glama
theodor90

form4api-mcp

get_convergence_signals

Read-only

Insider cluster-buy x congressional-purchase convergence (Pro plan+). Returns the tickers where an insider cluster-buy (InsiderSignal.IsClusterBuy) and at least one non-superseded congressional PURCHASE happened within window_days of EACH…

Instructions

Insider cluster-buy x congressional-purchase convergence (Pro plan+). Returns the tickers where an insider cluster-buy (InsiderSignal.IsClusterBuy) and at least one non-superseded congressional PURCHASE happened within window_days of EACH OTHER, restricted to convergences where the MORE RECENT of the pair's two dates is within a trailing lookback_days (so this surfaces CURRENT convergences, not ancient history). DEFINITION: for each result, insider.signalDate is the SignalDate of the qualifying cluster-buy signal with the most recent date (insider.insiderCount is that same signal's count — never summed or maxed across multiple signals), and congress is every non-superseded congressional purchase that paired with at least one qualifying cluster-buy (not every purchase in the window — only the ones that actually paired). firstSeen/lastSeen are the earliest/most recent dates among all qualifying insider and congress dates for that ticker. STRENGTH is documented arithmetic, NOT a black-box or predictive/ML score: strength = (distinct congressional purchasers among the qualifying legs) x (the representative signal's insiderCount) — a plain multiplication of two observed counts, nothing more. HONESTY: every congress leg always carries both amountLow and amountHigh (STOCK Act discloses ranges, never exact figures — never combined into a fabricated midpoint) and disclosureLagDays = (disclosureDate - transactionDate). Congressional trades whose dates are impossible or implausible (a dateQuality flag: transaction_after_disclosure, future_transaction_date or implausible_lag) are excluded from detection, so they never appear as legs and never create a convergence; dateQuality is therefore null on every leg returned here and disclosureLagDays is always set. Congressional trades are disclosed up to 45 days after the actual trade under the STOCK Act, so this endpoint is detection/monitoring of what insiders AND members of Congress have DISCLOSED buying, not a claim of predictive edge, alpha, or win rate — no performance numbers are computed or implied anywhere in this response. window_days and lookback_days are both caller-overridable with clamps (see each parameter's own description for the exact bounds). Requires Pro plan or higher (402 PLAN_REQUIRED on Free/Starter). limit is accepted as an alias for per_page. Query runs live against the database — no caching.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page number. Defaults to 1.
limitNoAlias for per_page.
tickerNoTicker symbol, case-insensitive exact match (e.g. "AAPL"). Omit to scan every ticker.
per_pageNoConverged tickers per page. Defaults to 100, maximum 500. `limit` is accepted as an alias; if both are given, per_page wins.
window_daysNoTrailing-day window: an insider cluster-buy date and a congressional purchase date must fall within this many days of EACH OTHER (either order) to count as a qualifying pair. Defaults to 30, clamped to [1, 90].
lookback_daysNoHow far back from now the MORE RECENT of a qualifying pair's two dates must fall to still count as a current convergence (the less-recent date in a pair can be older, as long as it's within window_days of a recent partner). Defaults to 180, clamped to [1, 730].

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.9.7
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "Alias for per_page.",
      +  "type": "integer"
      +}
    • changedInput schema / properties / per_page / description
      Previous value: -"Converged tickers per page. Defaults to 100, maximum 500."New value: +"Converged tickers per page. Defaults to 100, maximum 500. `limit` is accepted as an alias; if both are given, per_page wins."
  2. Addedv1.9.6

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only cover readOnlyHint and openWorldHint, so the description carries real weight and delivers: plan gating with the exact error code, live uncached query behavior, caller-overridable clamps on window_days/lookback_days, exclusion of implausible congressional dates, and an explicit disclaimer that no alpha/win-rate is computed. This is behavioral context well beyond the annotations.

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 core purpose and scoping are front-loaded, and the DEFINITION/HONESTY sections carry substantive return-value and disclosure semantics rather than filler. It is nonetheless a dense wall of ALL-CAPS prose with some repetition (e.g. the 'no predictive edge' point is made twice), which costs it the top mark.

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 fully documents the return shape: insider.signalDate, insider.insiderCount semantics, the congress leg set, firstSeen/lastSeen, the strength multiplication formula, amountLow/amountHigh ranges, disclosureLagDays, and dateQuality being null. Nothing an agent needs to interpret results is missing.

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

Parameters3/5

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 page, per_page/limit, ticker, window_days and lookback_days including their defaults, bounds and the alias rule. The description largely restates those (e.g. the alias and clamp notes), adding only marginal meaning, so the baseline 3 is appropriate.

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 precise compound resource (insider cluster-buy x congressional-purchase convergence) with the exact qualifying conditions, immediately distinguishing it from siblings like get_signals, get_key_activity and get_insider_transactions. An agent can tell what this tool returns without opening any schema.

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?

Gives clear context for use (detection/monitoring of disclosed insider AND congressional buying, not predictive edge) and a hard prerequisite (Pro plan+, 402 PLAN_REQUIRED on Free/Starter). It does not, however, explicitly name an alternative sibling or state when NOT to use it versus get_signals.

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