Skip to main content
Glama

Stockfacts

by io.github.AAAZZZR
OverviewDiscussionsAdmin

Politician trades (U.S. Congress: House and Senate)

get_politician_trades
Read-onlyIdempotent

Trades in stocks, ETFs, options and, on request, other assets reported by politicians (members of the U.S. Congress: House and Senate), one row per trade, newest report first by default. Filter by politician (bioguide ID or name), ticker, asset (listed by default, or stock, option, other, all), chamber, party, type (buy, sell, exchange), report filing dates (filed_from, filed_to) and trade dates (traded_from, traded_to). Each row has the politician (politician_bioguide, politician_name, party, chamber, state), the asset and reported ticker, asset_class, type (purchase, sale_full, sale_partial, sale or exchange), owner (self, spouse, joint or child), traded_date and filed_date, delay_days (days from the trade to its first report; null when the reported trade date is after the filing date, a typo flagged by trade_date_error), late (reported more than 45 days after the trade), the amount range, the official source_url, and livermore.club links for the politician and the stock (stock_url is null when the asset is not a listed company). totals summarize all trades matching the filters, not just this page. Data: House and Senate periodic transaction reports (PTRs) filed since 2020-01-01, from the U.S. House Clerk and the Senate Office of Public Records (eFD), updated daily. Only listed securities are included by default: stocks (including ADRs), ETFs and options, the assets with an exchange ticker. Politicians also report Treasury bills and notes, municipal and corporate bonds, private companies, private funds, crypto and other assets; pass asset=other for those or asset=all for everything. Amounts are the statutory ranges members of Congress report, not exact values: amount_min_usd to amount_max_usd, where a null amount_max_usd is an 'Over $X' range; estimated volumes add up range midpoints (an 'Over $X' range counts as X), so treat them as rough sizes. Trades replaced by an amendment and duplicates reported again in a later filing are left out. Paper and scanned reports are listed on politician pages but their trades are not read. At most 200 rows per call; use page for more.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number starting at 1; each page has `limit` rows. Check has_more.
sortNofiled = newest report first (default); traded = most recent trade first; amount = largest amount range first.filed
typeNobuy (purchases), sell (full, partial or unspecified sales) or exchange.
assetNoWhich assets to include: listed (default) = listed securities, that is stocks including ADRs, ETFs and options; stock = listed stocks and ETFs without options; option = options; other = Treasury bills and notes, municipal and corporate bonds, private companies, private funds, crypto and other assets; all = everything.listed
limitNoMaximum rows to return (1-200, default 25).
partyNodemocrat, republican or independent (the politician's latest party).
tickerNoOnly trades in this company (all its share classes, options and former tickers), e.g. MSFT. A ticker that is not a listed company (many ETFs and funds) matches the ticker as reported.
chamberNohouse or senate.
filed_toNoLatest filing date of the report, YYYY-MM-DD, inclusive.
traded_toNoLatest trade date, YYYY-MM-DD, inclusive.
filed_fromNoEarliest filing date of the report, YYYY-MM-DD.
politicianNoOnly this politician (a member of the U.S. Congress): a bioguide ID (e.g. P000197) or a name (e.g. Pelosi, Nancy Pelosi, Bernie Sanders). A name that matches several politicians returns an error listing them.
traded_fromNoEarliest trade date, YYYY-MM-DD.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
noteYes
pageYes
rowsYes
limitYes
stockYes
tickerYesThe ticker filter when it is not a listed company and is matched as reported.
totalsYes
filtersYes
has_moreYes
politicianYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial behavioral context: daily updates, 2020-01-01 coverage floor, exclusion of amended and duplicate trades, unreadable paper filings, null semantics for delay_days and amount_max_usd, and the 200-row-per-call cap with paging. This is far beyond what the annotations convey.

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?

The purpose is front-loaded and much of the content earns its place (asset filtering rules, amendment exclusions), but it is a single dense paragraph that also enumerates output fields. Because an output schema exists, that field-by-field return listing is largely redundant and inflates the length.

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 (13 params, multi-source disclosure data), the description covers data provenance, coverage dates, update cadence, deduplication/amendment handling, amount-range caveats, pagination, and default asset scope. An agent has everything needed to call it correctly; return-value detail is further backed by the output schema.

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 every parameter is already documented; the description mostly restates the same filters (asset classes, type values, date ranges). It adds minor value by clarifying that totals span all matching trades and that ticker matching behaves differently for non-listed tickers, but the baseline of 3 applies when the schema does the heavy lifting.

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 ('Trades... reported by politicians') with precise scope: U.S. Congress House and Senate, one row per trade. It distinguishes this from corporate-insider data by explicitly naming the data source (PTRs from the House Clerk and Senate eFD), letting an agent tell it apart from get_insider_trades without opening the 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: default returns only listed securities, and it routes the agent to asset=other or asset=all for bonds, crypto, private holdings, etc. It also notes paper/scanned reports have no readable trades. It doesn't explicitly name a sibling alternative (e.g., get_insider_trades vs this), so routing is inferred rather than spelled out.

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

All Stockfacts 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