Skip to main content
Glama

congressgov-mcp-server

Congress.gov Bill Lookup

congressgov_bill_lookup
Read-onlyIdempotent

Browse and retrieve U.S. legislative bill data from Congress.gov. Discover bills by filtering on congress, bill type, and date range — there is no keyword search. Use 'list' to browse (requires congress, defaults to most-recently-updated first), 'get' for full bill detail (sponsor, policy area, CBO estimates, law info), or drill into a specific bill with 'actions', 'amendments', 'cosponsors', 'committees', 'subjects', 'summaries', 'text', 'titles', or 'related' (each requires congress + billType + billNumber). 'text' lists the published versions and their format URLs; 'content' then reads one version's actual text, a bounded character window at a time.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoResults per page (1-250).
orderNoSort order for 'list' (sorts by update date). 'recent' (default) is newest first; 'oldest' is ascending. Ignored by other operations.recent
formatNoDocument format for 'content'. 'text' is GPO's Formatted Text — plain, pre-formatted print output, published for every document checked. 'xml' prefers United States Legislative Markup and falls back to Formatted XML; it exists on some bill text versions and on no committee report or Congressional Record article. PDF is not retrieved — read one at the format URLs 'text'/'articles' return.text
offsetNoPagination offset.
billTypeNoBill type code. Required for get and sub-resource operations.
congressYesCongress number (e.g., 118, 119).
operationYesWhich data to retrieve.
billNumberNoBill number. Required for get and sub-resource operations. Accepts the digit-string form list rows carry (e.g. "9479") as well as a number.
toDateTimeNoEnd of date range filter (ISO 8601). Same field semantics as fromDateTime.
fromDateTimeNoStart of date range filter (ISO 8601). Filters by the bill's update date — when Congress.gov last touched the record — not by the bill's latest legislative action.
characterLimitNoMaximum characters to return for 'content' (1-100000). Legislative documents run past a million characters, so a full bill takes several windows.
characterOffsetNoFirst character to return for 'content', 0-based. Offsets are exact and are never snapped to a section or paragraph break, so feeding the response's nextOffset back walks the whole document with every character returned exactly once.
textVersionIndexNoWhich text version 'content' reads, 0-based against the same order 'text' returns — 0 is the most recent version. Ignored by other operations.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
billNoDynamic upstream JSON record.
dataNoResult rows. Per-tool item shape is rendered in the markdown body.
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when results are empty, a page is past the end, or a caveat applies.
contentNoDynamic upstream JSON record.
paginationNoPagination metadata: total count and next offset.
totalCountNoTotal results across all pages.
effectiveQueryNoThe browse scope and applied filters.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark the tool readOnly, idempotent, and openWorld, and the description does not contradict them. It adds substantial behavioral detail beyond those hints: filtering by update date rather than legislative action, 'list' defaulting to most-recently-updated first, 'content' returning a bounded character window, exact offset semantics, and the fact that PDF is not retrieved. This is exactly the kind of non-obvious behavior an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence earns its place, front-loading the core purpose and the critical 'no keyword search' caveat. It organizes the operation menu and parameter requirements in a compact flow, and it does not repeat annotation or schema content unnecessarily.

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 13 parameters, multiple operation modes, and a rich output schema, the description is remarkably complete. It covers all operation families, their prerequisites, the text-vs-content distinction, format behavior, and pagination semantics. The output schema handles return-value details, so nothing needed to call the tool correctly is missing.

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 goes further by tying parameters to operation semantics: it explains which parameters each operation requires, how 'textVersionIndex' relates to the order returned by 'text', and how 'characterOffset' paginates through long documents. While much parameter detail lives in the schema, this operation-level guidance adds real meaning beyond the individual field descriptions.

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?

The description opens with a specific verb and resource: 'Browse and retrieve U.S. legislative bill data from Congress.gov', and immediately disambiguates scope with 'there is no keyword search'. It enumerates the distinct operations ('list', 'get', 'actions', 'content', etc.), making it easy to separate this tool from the sibling committee, member, and CRS tools.

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?

The description gives actionable routing: 'Use 'list' to browse', ''get' for full bill detail', and ''text' lists the published versions ... 'content' then reads one version's actual text'. It also states the parameter prerequisites for each mode ('each requires congress + billType + billNumber') and the exclusion ('there is no keyword search'), so an agent can confidently choose an operation.

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.

TDQS

A4.4/5.0
Disambiguation4/5

Each tool maps to a distinct Congress.gov content area, but a few boundaries overlap: bill_summaries vs. bill_lookup's summaries operation, committee_lookup's reports/nominations drill-downs vs. committee_reports/senate_nominations. The descriptions clarify the intended use cases, so an agent can mostly choose correctly.

Naming Consistency5/5

All tool names follow a uniform, predictable pattern: congressgov_ + snake_case noun phrase. Although the convention is noun-based rather than verb_noun, it is consistent across all 10 tools and clearly signals the data domain.

Tool Count5/5

Ten tools is well-scoped for a Congress.gov data server. Each tool covers a major content type—bills, summaries, committees, reports, CRS reports, the Record, enacted laws, members, votes, and nominations—without redundancy or filler.

Completeness4/5

The tool surface provides strong read coverage across bills, summaries, committees, reports, the Congressional Record, enacted laws, members, votes, and nominations. Minor gaps remain, such as no standalone amendments/treaties browsing and no keyword search across bills or members, but most workflows can be completed by chaining existing tools.