Skip to main content
Glama

get_roll_call_votes

Read-only

Returns congressional roll-call vote metadata (House + Senate) from api.congress.gov. Use this when the user asks about: recent votes in either chamber, votes on a specific bill, votes by date range, or to chain to per-member positions via the source_data_url. Sources: api.congress.gov v3 for House votes; senate.gov XML (legislative/LIS/roll_call_lists/) for Senate votes — joined into one collection. While senate.gov refuses our requests, newly cast Senate votes may come from Voteview, labelled source 'voteview' with a source_citation and a source_note (the Senate's question text and document links are missing), and are replaced by the senate.gov record when the Senate answers again. Captures roll-call (recorded) votes only — voice votes and unanimous-consent passages aren't roll calls and don't appear here. v1A returns vote-level metadata: chamber, roll call number, vote type, result, the legislation being voted on (linked via bill_id), and links to the Clerk's authoritative XML data. Per-member positions (yea/nay/present/not voting per bioguide_id) live in the XML at source_data_url; agents fetch that directly when they need member detail. v1.1 will add a separate roll_call_member_votes tool/ collection for queryable per-member positions. Vote identifiers are stable composite keys: '{chamber}-{congress}- {session}-{rcNumber}', e.g., 'house-119-1-240' or 'senate-119-1-15'. Common vote_type values: 'Yea-And-Nay' (regular recorded vote), '2/3 Yea-And-Nay' (suspension of rules, requires 2/3 majority), 'Recorded Vote', 'Quorum'. Common result values: 'Passed', 'Failed', 'Agreed to', 'Rejected', 'Motion Agreed To', 'Motion Failed'. When a vote is on a bill, legislation_type + legislation_number are populated and bill_id is set to the composite key — use that to join to get_bills. For procedural votes (motion to recommit, motion to adjourn, etc.), those fields may be empty. Amendment + Senate detail: House votes ON AN AMENDMENT carry amendment_number, amendment_author (sponsor + label), and amendment_type (e.g. 'HAMDT'). Senate votes carry vote_title (descriptive title — e.g. a confirmation or motion), measure (the specific measure a question references, e.g. 'S.Amdt. 5740'), and en_bloc_matters[] (one {issue, question, result} per matter when a batch of nominations is decided en bloc). All are empty / [] where not applicable.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum votes to return. Default 50, max 500.
sinceNoVote-start date lower bound (ISO YYYY-MM-DD inclusive).
untilNoVote-start date upper bound (ISO YYYY-MM-DD inclusive).
resultNoSubstring match against result text (e.g., 'passed', 'failed', 'agreed').
bill_idNoFilter to votes on a specific bill (composite key like '119-HR-134'). Use to chain a bill lookup → votes on that bill.
chamberNoFilter to House or Senate roll calls.
sort_byNoDefault: start_date (most recent votes first).
vote_idNoComposite vote identifier ('{chamber}-{congress}-{session}-{rcNumber}', e.g., 'house-119-1-240'). Direct doc lookup, fastest path.
congressNoCongress number (e.g., 119).
sort_orderNoDefault: desc.
session_numberNoSession within the Congress. Session 1 = first calendar year of the Congress; Session 2 = second year.
legislation_typeNoFilter to votes on a specific legislation type.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover read-only/open-world safety, but the description adds substantial operational context: senate.gov outages cause fallback to Voteview records labelled with source 'voteview' and missing question text/document links, later replaced by authoritative records; procedural votes may have empty legislation fields; amendment and en_bloc fields are empty where not applicable. This is well beyond what the annotations provide and materially affects interpretation of results.

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 purpose, then usage triggers, then source provenance, then field-level return notes – a sensible ordering. It is long and includes some content with limited selection value (the v1.1 roadmap note), but nearly every sentence carries decision-relevant information.

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 12 optional parameters and no output schema, the description carries the burden of describing returns and does so thoroughly: vote-level fields, bill linkage, amendment fields, Senate vote_title/measure/en_bloc_matters, and the location of member-level data. Nothing an agent needs to call or interpret this tool correctly 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 all 12 parameters are already documented, including vote_id format, bill_id chaining, and session_number semantics. The description largely restates these (composite key format, bill_id join) and the extra detail it supplies (common vote_type and result values) concerns returned fields rather than parameters. 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 specific verb and resource (returns congressional roll-call vote metadata for House and Senate) and immediately scopes it against related data: per-member positions live elsewhere (source_data_url), and bill joins go through get_bills. An agent can distinguish this from get_bills or get_member_profile without opening a 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?

Explicit when-to-use list ('recent votes, votes on a specific bill, votes by date range, chaining to per-member positions') plus an explicit exclusion: voice votes and unanimous-consent passages are not roll calls and won't appear. It also names the downstream alternatives (fetch XML at source_data_url, join via bill_id to get_bills), leaving little to inference.

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