Skip to main content
Glama

get_politician_trades

Read-onlyIdempotent

Get the stock trades one US House member reported on Periodic Transaction Reports (published by the Clerk of the US House): transaction date, notification date, filing date, owner (self, spouse, joint, dependent child), asset as printed, ticker when the filer printed one, purchase or sale, and the official amount range (lower and upper bound; the law asks for a range, not an amount). Reports lag the trade by up to 45 days. Every row links the source PDF. Example: politician="Josh Gottheimer", window="1y".

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": {
      "politician": "<politician>"
    },
    "name": "get_politician_trades"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax trades returned, newest first (default 200, max 2000).
formatNoOutput wire format for this MCP call. Default 'toon' (Token-Oriented Notation, fewest tokens, best for tabular rows). 'compact' = minified JSON. 'json' = pretty JSON for readability. The REST API always returns JSON regardless.
windowNo30d | 90d | 1y | 2y | all (default 1y), by transaction date.
politicianYesSlug from list_politicians (josh-gottheimer-nj) or a full or last name that matches exactly one member.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is low. The description still adds real behavioral context: reports lag the trade by up to 45 days, amounts are legally-reported ranges rather than exact values, ownership categories are enumerated, and every row links the source PDF. It does not mention pagination or ordering beyond 'newest first' being in the schema.

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?

Purpose and scope come first, followed by a compact field list, the 45-day lag caveat, the source-PDF guarantee, and a concrete example. The long enumerated clause is dense but every element is informative; no filler sentences.

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?

With no output schema, the description carries the burden of describing returns and does so thoroughly (dates, owner, asset, ticker, direction, amount range, PDF link) plus the reporting-lag caveat. Only minor gaps remain, such as ordering/pagination behavior beyond the limit parameter documented in the 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 all four parameters are already documented (slug-or-name matching, window tokens, limit bounds, format enum). The description adds only a worked example pairing politician and window, which is a modest aid rather than new semantic detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Get the stock trades one US House member reported on Periodic Transaction Reports') and scopes it to a single member and the Clerk of the House source. It implicitly separates itself from the broader sibling congress_trades by emphasizing one member, but never names that sibling, so an agent must infer the boundary.

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

Usage Guidelines3/5

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

Usage is only implied: the example ('politician="Josh Gottheimer", window="1y"') shows a typical call, and the member-scoped framing hints this is the per-politician lookup. There is no explicit when-to-use/when-not guidance and no pointer to congress_trades or list_politicians as alternatives (the list_politicians reference lives only in the schema).

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.