Skip to main content
Glama

KeyVex

get_congressional_trades

Read-only

Returns trade records disclosed by U.S. members of Congress under the STOCK Act — Senate eFD and House Clerk Periodic Transaction Reports (PTRs). Each record is one disclosed transaction by a member or their immediate family. The same filings are published free as news at https://keyvex.com/disclosures under 5 U.S.C. § 13107(c). Use this when the user asks about: who in Congress traded a specific stock, what trades a specific member made, recent congressional trading activity, or filings within a date range. Important: This data is disclosed trades, with reporting lag up to 45 days. The disclosure_date is when the public could first see the trade; the transaction_date is when the trade actually happened. For 'what did Congress just disclose buying' questions, sort by disclosure_date. For 'what did Congress hold around a specific market event', filter by transaction_date. Each amount is a range like '$1,001 - $15,000' (Senate filers report ranges, not exact amounts). The amount_min and amount_max fields parse those bounds for filtering. STOCK Act allows reporting in 11 standard ranges from $1,001 up to over $50,000,000. Each record's party is the party the member held on the date of the record (a trade's transaction date, a disclosure's filing date); for a date outside the member's terms in office, the party of their nearest term (the last one before that date, or the first one after it).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum records to return. Default 50, max 500.
ownerNoWho owns the asset. STOCK Act covers spouse and dependent children's trades too — this filter narrows to one ownership category.
sinceNoISO date (YYYY-MM-DD). Only records on or after this date, using sort_by as the date field.
untilNoISO date (YYYY-MM-DD). Only records on or before this date.
cursorNoPass the `next_cursor` from the previous response VERBATIM to fetch the next page. Keep every other filter and the sort identical while paging. Omit to start from the top.
tickerNoStock symbol filter, e.g. 'AAPL'. Case-insensitive. Leave empty to query across all tickers.
chamberNoFilter to one chamber. Senate PTRs are HTML-parsed from efdsearch.senate.gov. House PTRs are PDF-parsed from disclosures-clerk.house.gov.
sort_byNoField used by since/until and ordering. Default: disclosure_date (when the public first saw the trade).
min_amountNoFilter to trades with amount_min >= this value (USD). Use to focus on larger disclosed trades. Note: amount ranges are minimums, so '$1,001 - $15,000' has amount_min=1001.
sort_orderNoDefault: desc (most recent first).
bioguide_idNoMember's permanent congressional ID, e.g. 'C001035' for Susan Collins. Preferred over member_name when known. Pair with get_member_profile to enrich a trade with the member's party/state/committee assignments.
member_nameNoFull or partial member name; case-insensitive substring match. Examples: 'Collins', 'Pelosi'.
amendment_statusNoFilter by whether the row came from an original filing or an AMENDMENT. Default: all three, deliberately — most amendment rows are NOT duplicates, they are disclosures the amendment added (181 of 198 recent Senate amendment rows have no original). Use 'original' to exclude restatements, accepting that you will also drop genuinely new disclosures. 'unknown' is every House row: the Clerk index carries no amendment indicator, so it cannot be determined from the source.
transaction_typeNoFilter by disclosed transaction type. 'buy' = Purchase (P); 'sell' = Sale, full or partial (S); 'exchange' = Exchange (E) — bond maturities, corporate spin-offs, and share-class exchanges, which are disclosed trades too. Leave empty to include all three.
exclude_supersededNoDrop ORIGINAL disclosures that a later amendment restates. Default FALSE — they are returned, marked `superseded_by_amendment: true`, and the envelope carries `superseded_rows_included` plus a coverage_warning naming the count. ⚠ SET THIS WHENEVER YOU ARE SUMMING AMOUNTS. A member who amends a report has BOTH versions in the data — Boozman's Chevron trade appears as an amendment and an original, identical in every visible field under two report ids — so any total over the default response DOUBLE-COUNTS them. 2,360 of 13,642 original Senate rows are in that state (measured 2026-08-27). It is not the default because Senate amendments do not declare WHICH report they replace, so the match is made on member + transaction date + ticker + owner + asset name; dropping on that identity alone is a judgement the caller should make knowingly. House rows are never affected — the Clerk index carries no amendment indicator, so their status is 'unknown' and they are never marked.
include_non_open_marketNoPhase A v0.52.0 (2026-05-24): controls whether NON-MARKET events appear in the result. When false (honest default for direction queries), keeps ONLY OPEN_MARKET rows plus INSUFFICIENT_DATA rows (passthrough — unclassified is not the same as confirmed non-market, never silently dropped). Excludes both NON_OPEN_MARKET_TRANSFER (charitable contributions, gifts, donations detected in `comment`) AND EQUITY_COMP (rare for congressional but handled identically for parity). Honest-by-default: with transaction_type='buy'|'sell' → defaults to FALSE so a charitable contribution can't pollute a sell-total query. Without transaction_type → defaults to TRUE (everything tagged honestly). The transaction_type field on each row is NEVER mutated. Example: `member_name:'Pelosi', transaction_type:'sell'` by default EXCLUDES Pelosi's Trinity University contribution; `include_non_open_market:true` re-includes it. Envelope carries `unclassifiable_records_retained: N` when any INSUFFICIENT_DATA rows passed through.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare read-only/open-world/non-destructive; the description goes well beyond by disclosing the up-to-45-day reporting lag, the disclosure_date vs transaction_date distinction, that amounts are ranges not exact values (11 standard STOCK Act brackets), and how party is attributed for dates outside a member's terms. These are material interpretation caveats an agent cannot get from 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?

Front-loads what the tool returns, then usage, then the 'Important' caveats block — a sound ordering with no redundancy against the schema. It loses a point for the promotional sentence ('published free as news at https://keyvex.com/disclosures'), which does nothing to help an agent select or invoke the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter, no-output-schema tool, the description supplies the domain model an agent needs (lag, date semantics, ranges, amendment/supersession implications at a high level). The response envelope fields (superseded_rows_included, coverage_warning, unclassifiable_records_retained) are only explained in schema text, so return-shape expectations are not fully covered here.

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 description coverage is 100%, so the baseline is 3, but the description adds genuine query-level meaning: which date field to sort/filter on for which question, how amount ranges map to amount_min/amount_max for filtering, and what owner/party values actually represent. It does not touch the heaviest parameters (exclude_superseded, include_non_open_market), which remain schema-only.

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 ('Returns trade records disclosed by U.S. members of Congress under the STOCK Act') and pins the exact sources (Senate eFD and House Clerk PTRs), plus the granularity ('each record is one disclosed transaction by a member or their immediate family'). An agent can distinguish this from get_insider_transactions or get_annual_financial_disclosures on the entity alone.

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 explicit triggering questions ('who in Congress traded a specific stock', 'what trades a specific member made', 'recent congressional trading activity', 'filings within a date range') and even routes between sort_by choices for two question shapes. It does not name alternatives or state when NOT to use it (e.g., use get_member_profile for enrichment, which is only mentioned in the schema), so it stops short of a 5.

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.

Resources