congressgov-mcp-server
Server Details
Access U.S. congressional data - bills, votes, members, committees - via MCP.
- Status
- Healthy
- Uptime
- 99.9% over 38 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- cyanheads/congressgov-mcp-server
- GitHub Stars
- 1
- Server Listing
- congressgov-mcp-server
TDQS
Scored across 10 tools
Each tool targets a distinct Congress.gov resource: bills, bill summaries, committees, committee reports, CRS reports, daily record, enacted laws, members, roll votes, and nominations. Potential overlaps are explicitly disambiguated in descriptions — e.g., bill_lookup's 'summaries' operation vs. bill_summaries notes exactly when to use each, and committee_lookup vs committee_reports are clearly separate resources. No two tools appear to do the same thing.
All tools follow a consistent congressgov_<resource> snake_case pattern with uniform prefix, making the family instantly recognizable. The suffix varies by resource type (lookup, reports, record, laws, votes, nominations) rather than a uniform verb_noun structure, but the pattern is predictable and internally consistent across all ten tools.
Ten tools is squarely in the well-scoped range for a legislative data server covering the breadth of Congress.gov surface area. Each tool earns its place — bills, summaries, committees, reports, CRS, record, laws, members, votes, and nominations each map to a distinct major resource with no redundant tools.
The surface covers the core Congress.gov domain comprehensively: deep bill lifecycle (actions, amendments, cosponsors, committees, subjects, summaries, text, titles, related), committees, both report types, CRS reports, congressional record, enacted laws, members, votes, and nominations with confirmation pipeline data. Minor gaps exist — keyword search is explicitly absent, and standalone hearings/treaty documents lack dedicated lookup tools — but agents can accomplish core workflows without dead ends.
Available Tools
10 toolscongressgov_bill_lookupCongress.gov Bill LookupARead-onlyIdempotentInspect
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. 'summaries' takes an optional versionCode selector and returns each row's text a bounded character window at a time — a row past the window carries textTotalCharacters/textTruncated/textNextOffset, and characterOffset reads on from there.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1-250). | |
| order | No | Sort order for 'list' (sorts by update date). 'recent' (default) is newest first; 'oldest' is ascending. Ignored by other operations. | recent |
| format | No | Document 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 |
| offset | No | Pagination offset. | |
| billType | No | Bill type code. Required for get and sub-resource operations. | |
| congress | Yes | Congress number (e.g., 118, 119). | |
| operation | Yes | Which data to retrieve. | |
| billNumber | No | Bill number. Required for get and sub-resource operations. Accepts the digit-string form list rows carry (e.g. "9479") as well as a number. | |
| toDateTime | No | End of date range filter (ISO 8601). Same field semantics as fromDateTime. | |
| versionCode | No | Which summary version 'summaries' returns — the versionCode a summary row carries ('00' introduced, '49' public law). Selection runs over the bill's whole summary list, which Congress.gov publishes no filter for, and limit/offset then page the matching rows. Omit to return every version. Ignored by other operations. | |
| fromDateTime | No | Start 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. | |
| characterLimit | No | Maximum characters to return (1-100000) — for the document window on 'content', and for each row's summary text on 'summaries'. Legislative documents run past a million characters and an enacted bill's summary past two hundred thousand, so either takes several windows. | |
| characterOffset | No | First character to return, 0-based — of the document on 'content', and of every returned row's summary text on 'summaries'. Offsets are exact and are never snapped to a section or paragraph break, so feeding back the response's nextOffset (or a summary row's textNextOffset) walks the whole text with every character returned exactly once. | |
| textVersionIndex | No | Which text version 'content' reads, 0-based against the same order 'text' returns — 0 is the most recent version. Ignored by other operations. |
Output Schema
| Name | Required | Description |
|---|---|---|
| bill | No | Dynamic upstream JSON record. |
| data | No | Result rows. Per-tool item shape is rendered in the markdown body. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when results are empty, a page is past the end, or a caveat applies. |
| content | No | Dynamic upstream JSON record. |
| pagination | No | Pagination metadata: total count and next offset. |
| totalCount | No | Total results across all pages. |
| effectiveQuery | No | The browse scope and applied filters. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent, and the description adds substantial behavior beyond that: bounded character windows with exact offsets, textTotalCharacters/textTruncated/textNextOffset cursor mechanics, filtering by update date rather than legislative action, format fallback rules for XML, and PDF non-retrieval. This is far more than annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with the purpose, and every sentence conveys useful information. However, it is a long single paragraph that mixes operation guidance with parameter nuances; bulleted or labeled sub-sections would improve scanability without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, 12 operations, output schema present), the description covers operation-specific requirements, pagination and windowing mechanics, date filtering semantics, and format behaviors. Little is left for the agent to infer, and the existing output schema handles return-value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description enriches several parameters well beyond their schema entries. Examples include 'fromDateTime' filtering semantics, the digit-string form for 'billNumber', the versionCode selection behavior, textVersionIndex ordering, and the exactness of characterOffset. This significantly reduces misconfiguration risk.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and verb: 'Browse and retrieve U.S. legislative bill data from Congress.gov.' It also scopes the tool by noting the absence of keyword search. However, it does not explicitly differentiate from the sibling congressgov_bill_summaries, which overlaps with the 'summaries' operation offered here, so sibling distinction is incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear internal guidance is provided: 'Use ''list'' to browse', ''get'' for full bill detail', and 'drill into a specific bill with...' operations, including required parameters for each. It does not, however, discuss when to prefer a sibling tool over this one, so no exclusions or alternative selection criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_bill_summariesCongress.gov Bill SummariesARead-onlyIdempotentInspect
Browse recent CRS (Congressional Research Service) bill summaries — plain-language summaries of bills at each legislative stage, useful for answering "what's happening in Congress?". The fromDateTime/toDateTime filters apply to the summary's update time, not the bill's action date, so results include recently rewritten summaries of older bills. Defaults to summaries updated in the last 7 days. Each item shows both the bill's action date and the summary update date. A page stops adding rows once it reaches a fixed response-character budget, and a summary longer than the per-row window arrives as an exact character window carrying textTotalCharacters/textTruncated/textNextOffset; pagination.nextOffset continues the page and a row's textNextOffset continues its text. For summaries of one specific bill — and to read a windowed summary to the end — use congressgov_bill_lookup with operation='summaries' instead.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1-250). | |
| offset | No | Pagination offset. | |
| billType | No | Bill type filter. Requires 'congress'. | |
| congress | No | Congress number. Optional — omit for summaries across all congresses. | |
| toDateTime | No | End of date range (ISO 8601), filtered on the summary update time. Defaults to now. | |
| fromDateTime | No | Start of date range (ISO 8601), filtered on the summary update time. Defaults to 7 days ago if neither date param is set. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Result rows. Per-tool item shape is rendered in the markdown body. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when results are empty, a page is past the end, or a caveat applies. |
| pagination | No | Pagination metadata: total count and next offset. |
| totalCount | No | Total results across all pages. |
| effectiveQuery | No | The browse scope and applied filters. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint and idempotentHint already set, the description adds substantial behavioral detail: the update-time versus action-date distinction, response-character budget pagination, text windowing with textTotalCharacters/textTruncated/textNextOffset, and how pagination.nextOffset and textNextOffset work. This goes well beyond the annotations and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is long, it is dense with necessary operational detail and every sentence earns its place. The core purpose is front-loaded, followed by filter semantics, pagination/truncation mechanics, and the sibling alternative in a logical order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and all parameters fully described, the description covers invocation, pagination, text truncation behavior, default date ranges, and the correct alternative tool. An agent has everything needed to call this tool correctly and interpret the result windowing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all parameters with 100% coverage, so this is above baseline. The description adds meaning by clarifying that fromDateTime/toDateTime apply to summary update time rather than bill action datehola, and that results can include recently rewritten summaries of older bills. It also confirms the default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Browse recent CRS bill summaries') and immediately clarifies the tool's purpose with a use case. It also distinguishes this tool from the sibling congressgov_bill_lookup by explicitly saying to use that tool instead for summaries of one specific bill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool versus congressgov_bill_lookup, including the exact operation for the alternative. It also explains the date filter semantics and default 7-day behavior, leaving no ambiguity about invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_committee_lookupCongress.gov Committee LookupARead-onlyIdempotentInspect
Browse congressional committees and their legislation, reports, and nominations. Committee codes follow the pattern chamber-prefix (h/s/j) + abbreviation + 2-digit number — use 'list' (with optional 'filter' for name→code resolution) to discover codes, then 'get' or drill into 'bills', 'reports', or 'nominations' ('nominations' is Senate-only). 'get' and sub-resources only need committeeCode (chamber is inferred from the prefix); pass chamber explicitly to override. The 'bills' sub-resource defaults to 'recent' order (newest update-date first); pass order='oldest' for ascending update-date order. Upstream omits bill titles from the 'bills' sub-resource — rows carry only {congress, billType, billNumber, actionDate, relationshipType, url}; chain 'congressgov_bill_lookup get' per row to retrieve titles and policy area.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1-250). | |
| order | No | Sort order for the 'bills' sub-resource. 'recent' (default) returns newest update-date first; 'oldest' returns ascending update-date order. Ignored by other operations. | recent |
| filter | No | Filter committee-list results by name (e.g., 'transportation', 'armed services'). Only meaningful for 'list'; fuzzy-matched rows are labeled approximate. | |
| offset | No | Pagination offset. | |
| chamber | No | Chamber filter for 'list', or override for 'get' and sub-resources (otherwise inferred from committeeCode prefix). | |
| congress | No | Congress number. | |
| operation | Yes | Which data to retrieve. | |
| committeeCode | No | Committee system code, e.g. 'hsju00'. Required for 'get' and sub-resources. Codes are letters + a 2-digit suffix and are matched case-insensitively. Any other non-blank value is treated as a committee name and resolved automatically — single-word names ('Judiciary') included — or use operation:'list' with filter to browse. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Result rows. Per-tool item shape is rendered in the markdown body. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when results are empty, a page is past the end, or a caveat applies. |
| committee | No | Dynamic upstream JSON record. |
| pagination | No | Pagination metadata: total count and next offset. |
| totalCount | No | Total results across all pages. |
| effectiveQuery | No | The browse scope and applied filters. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and idempotentHint already present, the description adds valuable non-obvious behaviors: committee code inference from the prefix, approximate fuzzy-match labels, the 'bills' default ordering, and the upstream limitation that bill titles are omitted. These go well beyond what annotations or schema could convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds decision-relevant detail: operation flow, code syntax, chamber handling, ordering behavior, and data limitations. Information is front-loaded with the overall purpose, then logically progresses from discovery to retrieval to chaining.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's eight parameters, five operations, and an output schema, the description covers all necessary context: operation selection, parameter dependencies, default behaviors, Senate-only restriction, and how to overcome the missing-titles gap by chaining to another tool. Nothing an agent needs to invoke it correctly is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3, but the description substantially enriches parameter semantics. It explains the internal structure and case-insensitivity of committeeCode, reveals that any non-blank value is auto-resolved as a committee name, and clarifies the order parameter's scope and defaults beyond the schema's enum text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair ('Browse congressional committees and their legislation, reports, and nominations') and enumerates the exact sub-operations, making it immediately distinguishable from sibling bill, member, and report tools. It also names the chaining target (congressgov_bill_lookup get), reinforcing its role in the broader tool family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit workflow: use 'list' (with optional 'filter') to discover committee codes, then use 'get' or sub-resources. It also gives exclusion guidance ('nominations' is Senate-only) and explains when chamber should be passed explicitly versus inferred, leaving no ambiguity about operation selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_committee_reportsCongress.gov Committee ReportsARead-onlyIdempotentInspect
Browse and retrieve committee reports from Congress.gov — reports accompany legislation reported out of committee and explain the bill's purpose, committee amendments, dissenting views, and the committee vote. Report types are 'hrpt' (House), 'srpt' (Senate), and 'erpt' (Executive). 'text' lists the published format URLs; 'content' then reads the report's actual text, a bounded character window at a time.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1-250). | |
| format | No | Document 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 |
| offset | No | Pagination offset. | |
| congress | Yes | Congress number. | |
| operation | Yes | Which data to retrieve. | |
| reportType | No | Report type. Required for get, text, and content operations. | |
| reportNumber | No | Committee report number. Required for get, text, and content operations. | |
| characterLimit | No | Maximum characters to return for 'content' (1-100000). Legislative documents run past a million characters, so a full bill takes several windows. | |
| characterOffset | No | First 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Result rows. Per-tool item shape is rendered in the markdown body. |
| text | No | Dynamic upstream JSON records. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when results are empty, a page is past the end, or a caveat applies. |
| report | No | Dynamic upstream JSON record. |
| content | No | Dynamic upstream JSON record. |
| pagination | No | Pagination metadata: total count and next offset. |
| totalCount | No | Total results across all pages. |
| effectiveQuery | No | The browse scope and applied filters. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only/idempotent, and the description adds useful behavioral detail: 'content' reads a bounded character window at a time and 'text' returns format URLs rather than full documents. This gives an agent an accurate model of how retrieval progresses, though pagination/rate-limit behavior is not discussed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about three sentences and every sentence contributes: purpose, report-type taxonomy, and the text/content retrieval flow. It is front-loaded with the core action and contains no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and an output schema, the description is largely complete: it explains the main workflow, the report type taxonomy, and the bounded nature of content reads. It does not spell out the semantics of the 'list' and 'get' operations, but the schema and output schema already supply the remaining structured detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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; the description adds value by explaining the sequencing of the text and content operations and by defining report types. It does not independently document limit/offset or character parameters, but those are already well described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific verb ('browse and retrieve') and resource ('committee reports from Congress.gov'), and reinforces scope with report types and the text/content workflow. It does not explicitly differentiate from sibling tools such as congressgov_committee_lookup, so it stops one step short of full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear operational guidance: use 'text' to get published format URLs, then 'content' to read the report text in bounded windows, and it maps report types to chambers. It does not explicitly state when to choose this tool over sibling tools or list exclusions, but the intended workflow is clearly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_crs_reportsCongress.gov CRS ReportsARead-onlyIdempotentInspect
Browse and retrieve CRS (Congressional Research Service) reports — nonpartisan policy analyses by subject-matter experts at the Library of Congress, covering policy areas, legislative proposals, and legal questions. Report IDs use letter-number codes (e.g., R40097, RL33612, IF12345). Use 'list' to browse available reports or 'get' for full detail (authors, topics, summary, download formats).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1-250). | |
| offset | No | Pagination offset. | |
| operation | Yes | Which data to retrieve. | |
| reportNumber | No | CRS report ID (e.g., 'R40097'). Required for 'get'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Result rows. Per-tool item shape is rendered in the markdown body. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when results are empty, a page is past the end, or a caveat applies. |
| report | No | Dynamic upstream JSON record. |
| pagination | No | Pagination metadata: total count and next offset. |
| totalCount | No | Total results across all pages. |
| effectiveQuery | No | The browse scope and applied filters. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, establishing safe read-only behavior. The description adds behavioral context by noting that 'get' provides authors, topics, summary, and download formats, and that report IDs follow a letter-number pattern (e.g., R40097). This enhances the agent's understanding of what to expect without contradicting 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with no redundancy. The first sentence establishes what CRS reports are, and the second explains the operations and ID format. The key actionable information (list vs get, ID format) is front-loaded, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with an output schema and well-documented parameters, the description adequately covers the essential usage details: the operations, the report ID format, and what 'get' returns. It doesn't mention pagination or error handling, but those are covered by the schema and the tool's read-only nature. Minor omission of how 'list' results are returned is tolerable given the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all parameters with 100% coverage, including descriptions and defaults. The description adds value by specifying the concrete report number format ('R40097', 'RL33612', 'IF12345') and clarifying that reportNumber is required for 'get', which reinforces the schema's conditional requirement. This goes beyond the schema's generic wording.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses and retrieves CRS reports, explicitly describing them as nonpartisan policy analyses covering policy areas, legislative proposals, and legal questions. This distinguishes it from sibling tools for bills, committee reports, and other congressional documents, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on how to use the two operations: 'Use 'list' to browse available reports or 'get' for full detail'. It also clarifies the report ID format required for 'get'. While it doesn't explicitly contrast with sibling tools or state when not to use this tool, the topic distinction (CRS reports vs. other congressional documents) is implied through the description's content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_daily_recordCongress.gov Daily RecordARead-onlyIdempotentInspect
Browse the daily Congressional Record — floor speeches, debates, and legislative text published each day Congress is in session. Navigation is hierarchical: volumes (via 'list') → issues (via 'issues') → articles (via 'articles'). Use 'list' to find recent volumes, 'issues' to see what's in a volume, and 'articles' to access individual speeches and debate sections. 'articles' lists each article and its format URLs; 'content' then reads one article's actual text, a bounded character window at a time.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1-250). | |
| format | No | Document 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 |
| offset | No | Pagination offset. | |
| operation | Yes | Which data to retrieve. | |
| issueNumber | No | Issue number within a volume. Required for 'articles' and 'content'. List rows carry this as a string (e.g. "109") — both forms are accepted. | |
| articleIndex | No | Which article 'content' reads, 0-based against the issue's whole article sequence — the same absolute position 'articles' pages through with offset. Ignored by other operations. | |
| volumeNumber | No | Volume number. Required for 'issues', 'articles', and 'content'. Accepts a number or the digit-string form list rows carry. | |
| characterLimit | No | Maximum characters to return for 'content' (1-100000). Legislative documents run past a million characters, so a full bill takes several windows. | |
| characterOffset | No | First 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Result rows. Per-tool item shape is rendered in the markdown body. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when results are empty, a page is past the end, or a caveat applies. |
| content | No | Dynamic upstream JSON record. |
| pagination | No | Pagination metadata: total count and next offset. |
| totalCount | No | Total results across all pages. |
| effectiveQuery | No | The browse scope and applied filters. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, it reveals behavioral details: navigation is hierarchical, article listing exposes format URLs, and content reads return 'a bounded character window at a time.' No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the resource and content, then a compact operation map. Every phrase earns its place and the repeated 'via X' structure keeps it scannable without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex nine-parameter, multi-operation tool, the description supplies the navigation skeleton — list → issues → articles → content — and the windowed-read behavior. Parameter details and return shapes are covered by the fully described schema and output schema, so nothing an agent needs to begin correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The tool description adds little parameter-level meaning beyond mapping operation names to navigation steps and hinting at windowed reading; volume, issue, offset, and format semantics are already well documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 the daily Congressional Record' — and enumerates contained content: floor speeches, debates, and legislative text. This makes it unmistakable against siblings like bill_lookup or committee_reports, and the operation names reinforce its distinct scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly maps each operation to a use case: 'list' to find volumes, 'issues' to inspect a volume, 'articles' to access speeches, and 'content' for text. It gives clear context but does not name sibling tools or state when not to use this tool, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_enacted_lawsCongress.gov Enacted LawsARead-onlyIdempotentInspect
Browse enacted public and private laws from Congress.gov by congress and law type ('pub' for public laws, 'priv' for private). 'list' filters by enactment status and law type — the discovery path 'bill_lookup' does not offer. 'get' returns the origin bill record (sponsor, actions, summaries, text), with the public/private law citation on the bill's 'laws' array (e.g. {"number":"118-2","type":"Public Law"}).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1-250). | |
| offset | No | Pagination offset. | |
| lawType | No | Law type — 'pub' (public laws, general application, most common) or 'priv' (private laws, specific individuals or entities). Required for 'get'. | |
| congress | Yes | Congress number. | |
| lawNumber | No | Law number, as carried by a 'list' row's `laws[].number` — either the full citation ('118-90', rendered as 'Public Law 118-90') or the portion after the hyphen ('90'); the prefix is the congress and must match `congress`. Not the row's own `number`, which is the origin bill. Required for 'get'. | |
| operation | Yes | Which data to retrieve. |
Output Schema
| Name | Required | Description |
|---|---|---|
| law | No | Dynamic upstream JSON record. |
| data | No | Result rows. Per-tool item shape is rendered in the markdown body. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when results are empty, a page is past the end, or a caveat applies. |
| pagination | No | Pagination metadata: total count and next offset. |
| totalCount | No | Total results across all pages. |
| effectiveQuery | No | The browse scope and applied filters. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description doesn't need to restate safety. It adds meaningful behavioral context by explaining that 'get' returns the origin bill record with the law citation on the 'laws' array, including an example. This goes beyond the schema and gives the agent an expectation of the output shape. No contradictions with annotations were found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with zero fluff. The first sentence states the overall scope, the second explains 'list', and the third explains 'get'. The most important differentiator (list's filtering ability) is front-loaded, and the example citation is compact and concrete. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two operations, six parameters, and an output schema present, the description handles the essentials well: it explains each operation's purpose and return, and it ties lawType and lawNumber to the operations. Pagination (limit/offset) is left to the schema, which is acceptable given the schema is explicit. The description could mention the typical workflow (list then get) more explicitly, but it's implied strongly enough that an agent can infer it. Overall, it's complete for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already defines every parameter. The description adds genuine semantic value beyond the schema: it clarifies the meaning of 'pub' vs 'priv' (public/private laws) and explains that lawNumber is carried from a 'list' row's laws[].number, with the prefix matching congress. This extra context helps disambiguate the lawNumber parameter's dual forms, which the schema describes but the description makes operationally clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: browse enacted public and private laws from Congress.gov by congress and law type. It explicitly names the two operations ('list' and 'get') and what each does, and it differentiates from the sibling bill_lookup by noting that 'list' offers enactment-status and law-type filtering that bill_lookup lacks. This gives an agent a confident understanding of what the tool does and how it differs from nearby tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies the discovery path ('list') and the retrieval path ('get'), and it explicitly calls out that bill_lookup does not offer the filtering 'list' provides, giving a concrete when-to-use hint. It doesn't enumerate all alternative tools or provide explicit exclusions for every sibling, but the domain (enacted laws) is distinct enough that the usage context is clear. A bit more explicit 'use this when...' phrasing would push it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_member_lookupCongress.gov Member LookupARead-onlyIdempotentInspect
Discover congressional members and their legislative activity. No name search. For 'list', filter by stateCode (optionally with district), by congress, or by both together (e.g., 118th Congress + CA, or CA district 12 in the 118th). Add currentMember=true to restrict to currently serving members. Once you have a bioguideId, use 'get' for full profile or 'sponsored'/'cosponsored' for their legislative portfolio.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1-250). | |
| offset | No | Pagination offset. | |
| congress | No | Congress number to filter by. | |
| district | No | Congressional district number. Requires stateCode. Use 0 for at-large. | |
| operation | Yes | Which data to retrieve. | |
| stateCode | No | Two-letter state code (e.g., 'CA', 'TX'). | |
| bioguideId | No | Unique member identifier (e.g., 'P000197'). Required for get/sponsored/cosponsored. | |
| currentMember | No | Filter to currently serving members. Omit to include both current and former members. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Result rows. Per-tool item shape is rendered in the markdown body. |
| error | No | Present when the call failed. Absent on success. |
| member | No | Dynamic upstream JSON record. |
| notice | No | Guidance when results are empty, a page is past the end, or a caveat applies. |
| pagination | No | Pagination metadata: total count and next offset. |
| totalCount | No | Total results across all pages. |
| effectiveQuery | No | The browse scope and applied filters. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply readOnly, idempotent, and openWorld hints. The description adds meaningful behavioral context beyond those: it states that name search is not supported, that currentMember=true restricts to currently serving members, and that 'list' filtering follows specific combination patterns. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences carry a large amount of operational guidance without fluff. The most important scoping caveat ('No name search') and the filtering rules are front-loaded, and the workflow progression from list to get/sponsored/cosponsored is logically structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with four operations, the description covers filter combinations, required dependencies, operation selection once bioguideId is known, and an explicit exclusion. Combined with a 100% described schema, rich annotations, and an output schema, nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying relationships: district requires stateCode, stateCode can pair with congress, and bioguideId is the key for get/sponsored/cosponsored. Concrete examples (e.g., 'CA district 12 in the 118th') reinforce parameter semantics beyond dry schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('congressional members and their legislative activity') with a clear verb ('Discover') and immediately delimits scope with 'No name search.' It also names the four operation modes, making the tool's purpose and boundaries obvious relative to sibling lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage patterns for the 'list' operation—filter by stateCode, optionally with district, by congress, or both—and explains when to switch to 'get' or 'sponsored'/'cosponsored' once a bioguideId is known. It doesn't explicitly compare to sibling tools, but the domain and operation guidance are clear enough for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_roll_votesCongress.gov Roll VotesARead-onlyIdempotentInspect
Retrieve U.S. congressional roll call votes and individual member voting positions for either chamber. Set 'chamber' to 'house' (default, from the Congress.gov API) or 'senate' (from the Senate's official LIS feed). Use 'list' to find votes by congress and session (newest first by default), 'get' for vote details (question, result, tallies, party breakdown, associated bill/nomination/amendment), or 'members' for how each member voted.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1-250). | |
| order | No | Sort order for 'list'. 'recent' (default) returns newest first; 'oldest' returns ascending. House sorts by vote update date (with 'recent', offset=0 always returns the strictly newest page); Senate sorts by roll call number. Ignored by 'get' and 'members'. | recent |
| offset | No | Pagination offset. | |
| chamber | No | Chamber whose votes to query. 'house' (default) draws from the Congress.gov API; 'senate' draws from the Senate's official LIS roll-call feed. Roll call numbers reset each session and are specific to one chamber. | house |
| session | Yes | Session number (1 or 2). Odd years are session 1, even years session 2. | |
| congress | Yes | Congress number. | |
| operation | Yes | Which data to retrieve. | |
| voteNumber | No | Roll call vote number. Required for 'get' and 'members'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Result rows. Per-tool item shape is rendered in the markdown body. |
| vote | No | Dynamic upstream JSON record. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when results are empty, a page is past the end, or a caveat applies. |
| pagination | No | Pagination metadata: total count and next offset. |
| totalCount | No | Total results across all pages. |
| effectiveQuery | No | The browse scope and applied filters. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context: house data comes from the Congress.gov API while senate data comes from the Senate's LIS feed, list returns newest first by default, and 'get' returns specific fields (question, result, tallies, party breakdown, associated bill/nomination/amendment). This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and each sentence earns its place. It efficiently packs chamber sourcing, operation types, and return content without redundancy or filler. The structure is scannable and immediately actionable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers operation semantics, chamber selection, data sources, and default ordering. The input schema documents all parameters, and an output schema exists, so return values are already specified. Minor gaps like pagination behavior are handled by the schema; overall, the agent has everything needed to select and invoke the tool correctly. A 4 is appropriate given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description does not add much parameter-level meaning beyond the schema: it mentions operation-to-parameter mapping and the chamber data source, but the schema already documents voteNumber's requirement for 'get'/'members' and the chamber-specific roll call reset behavior. No significant param semantics are added beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair ('Retrieve U.S. congressional roll call votes and individual member voting positions') and immediately distinguishes the tool's domain from the sibling tools (bill lookup, committee reports, etc.). It further clarifies scope by chamber and by operation, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit operation selection guidance: 'Use 'list'...', 'get' for vote details..., or 'members' for how each member voted.' It also distinguishes data sources for house vs senate. It does not explicitly state when not to use this tool versus a sibling, but the sibling tools are clearly different domains, so exclusion guidance is unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_senate_nominationsCongress.gov Senate NominationsARead-onlyIdempotentInspect
Browse presidential nominations to federal positions and track the Senate confirmation process. Use 'list' to browse, 'get' for nomination detail, 'actions'/'committees'/'hearings' for confirmation pipeline data, or 'nominees' to retrieve individual appointees in a multi-nominee batch. Nominations use 'PN' (Presidential Nomination) numbering. Most nominations carry confirmation activity on the parent (e.g., PN1000); multi-part parents (e.g., PN851) carry no activity of their own — their actions, committees, hearings, and nominees live on partitioned children (PN851-1, PN851-2, …). 'get' on a parent that has no nominees array signals the partitioned form is needed for everything below it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1-250). | |
| offset | No | Pagination offset. | |
| ordinal | No | Batch ordinal within a multi-nominee nomination. Each ordinal addresses a group of nominees; the 'nominees' operation returns every individual in that batch. Use 'get' first to see available ordinals on the nomination's `nominees` array (multi-part parents have no nominees array — use a partitioned form like '851-1' instead). | |
| congress | Yes | Congress number. | |
| operation | Yes | Which data to retrieve. | |
| nominationNumber | No | Nomination number. Use the bare form (e.g. '1000') for nominations whose activity sits on the parent; use the partitioned form (e.g. '851-1') for sub-resources of a multi-part nomination. Required for detail operations. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Result rows. Per-tool item shape is rendered in the markdown body. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when results are empty, a page is past the end, or a caveat applies. |
| nomination | No | Dynamic upstream JSON record. |
| pagination | No | Pagination metadata: total count and next offset. |
| totalCount | No | Total results across all pages. |
| effectiveQuery | No | The browse scope and applied filters. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/openWorld annotations, the description discloses crucial non-obvious behavior: parent nominations like PN1000 carry activity, while multi-part parents like PN851 carry none and require partitioned children. It even provides a diagnostic rule—'get on a parent that has no nominees array signals the partitioned form is needed'—which is exactly the kind of behavioral nuance 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, operation routing, numbering scheme, parent/child quirk, and a detection heuristic. The most important operational constraint is front-loaded with concrete examples, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—six operations, nuanced multi-part nominations, and partition behavior—the description covers everything needed to select and invoke it correctly. The presence of an output schema means return values need not be explained in prose, and the HTTP-like safety profile is covered by annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the input schema already documents operation, nominationNumber, ordinal, congress, limit, and offset in detail. The description adds a useful decision procedure for choosing bare vs partitioned nomination numbers, but largely restates semantics already present in the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 presidential nominations to federal positions and track the Senate confirmation process.' It then enumerates the exact operations and what each returns, making the tool's purpose unmistakable and clearly distinct from the unrelated congressional siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit operation-by-operation routing: 'Use list to browse, get for nomination detail, actions/committees/hearings for confirmation pipeline data, or nominees to retrieve individual appointees.' It also explains when to use bare versus partitioned nomination numbers, so an agent knows exactly how to select parameters for the right data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
- Changed
congressgov_bill_lookup4 fields changed- changed
Input schema / properties / characterLimit / descriptionPrevious value: -"Maximum characters to return for 'content' (1-100000). Legislative documents run past a million characters, so a full bill takes several windows."New value: +"Maximum characters to return (1-100000) — for the document window on 'content', and for each row's summary text on 'summaries'. Legislative documents run past a million characters and an enacted bill's summary past two hundred thousand, so either takes several windows." - changed
Input schema / properties / characterOffset / descriptionPrevious value: -"First 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."New value: +"First character to return, 0-based — of the document on 'content', and of every returned row's summary text on 'summaries'. Offsets are exact and are never snapped to a section or paragraph break, so feeding back the response's nextOffset (or a summary row's textNextOffset) walks the whole text with every character returned exactly once." - added
Input schema / properties / versionCodeAdded value: +{ + "description": "Which summary version 'summaries' returns — the versionCode a summary row carries ('00' introduced, '49' public law). Selection runs over the bill's whole summary list, which Congress.gov publishes no filter for, and limit/offset then page the matching rows. Omit to return every version. Ignored by other operations.", + "type": "string" +} - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `not_found`: A requested bill, member, committee, report, vote, or nomination does not exist in Congress.gov. `rate_limited`: The Congress.gov API rate limit (5,000 requests/hour per key) was exceeded. `invalid_request`: Congress.gov rejected the request as malformed — a bad date range or an identifier with an unexpected shape. `upstream_error`: Congress.gov returned an unexpected error (5xx or another non-2xx status). `document_unavailable`: The 'content' selection resolves to no retrievable document — the text version or article index is past the end of the list, the record publishes no formats at all, or Congress.gov does not hold the file its own metadata names. `format_unavailable`: The document exists but publishes nothing in the requested 'format' — some text versions and committee reports ship PDF only, and no Congressional Record article publishes XML. `document_fetch_failed`: www.congress.gov did not return a readable document — a non-2xx status, a network failure, an empty body, or a content type that is not text or XML. `document_too_large`: The document is larger than the byte ceiling this server retrieves, so no character window can be served from it. `offset_past_end`: characterOffset is at or beyond the last character of the document, so the window would be empty. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `not_found`: A requested bill, member, committee, report, vote, or nomination does not exist in Congress.gov. `rate_limited`: The Congress.gov API rate limit (5,000 requests/hour per key) was exceeded. `invalid_request`: Congress.gov rejected the request as malformed — a bad date range or an identifier with an unexpected shape. `upstream_error`: Congress.gov returned an unexpected error (5xx or another non-2xx status). `document_unavailable`: The 'content' selection resolves to no retrievable document — the text version or article index is past the end of the list, the record publishes no formats at all, or Congress.gov does not hold the file its own metadata names. `format_unavailable`: The document exists but publishes nothing in the requested 'format' — some text versions and committee reports ship PDF only, and no Congressional Record article publishes XML. `document_fetch_failed`: www.congress.gov did not return a readable document — a non-2xx status, a network failure, an empty body, or a content type that is not text or XML. `document_too_large`: The document is larger than the byte ceiling this server retrieves, so no character window can be served from it. `offset_past_end`: characterOffset is at or beyond the last character of every text the call would window — the document on 'content', or every returned row's summary text on 'summaries' — so the window would be empty. Other values are possible when a failure originates below the handler."
- Changed
congressgov_committee_reports1 field changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `not_found`: A requested bill, member, committee, report, vote, or nomination does not exist in Congress.gov. `rate_limited`: The Congress.gov API rate limit (5,000 requests/hour per key) was exceeded. `invalid_request`: Congress.gov rejected the request as malformed — a bad date range or an identifier with an unexpected shape. `upstream_error`: Congress.gov returned an unexpected error (5xx or another non-2xx status). `document_unavailable`: The 'content' selection resolves to no retrievable document — the text version or article index is past the end of the list, the record publishes no formats at all, or Congress.gov does not hold the file its own metadata names. `format_unavailable`: The document exists but publishes nothing in the requested 'format' — some text versions and committee reports ship PDF only, and no Congressional Record article publishes XML. `document_fetch_failed`: www.congress.gov did not return a readable document — a non-2xx status, a network failure, an empty body, or a content type that is not text or XML. `document_too_large`: The document is larger than the byte ceiling this server retrieves, so no character window can be served from it. `offset_past_end`: characterOffset is at or beyond the last character of the document, so the window would be empty. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `not_found`: A requested bill, member, committee, report, vote, or nomination does not exist in Congress.gov. `rate_limited`: The Congress.gov API rate limit (5,000 requests/hour per key) was exceeded. `invalid_request`: Congress.gov rejected the request as malformed — a bad date range or an identifier with an unexpected shape. `upstream_error`: Congress.gov returned an unexpected error (5xx or another non-2xx status). `document_unavailable`: The 'content' selection resolves to no retrievable document — the text version or article index is past the end of the list, the record publishes no formats at all, or Congress.gov does not hold the file its own metadata names. `format_unavailable`: The document exists but publishes nothing in the requested 'format' — some text versions and committee reports ship PDF only, and no Congressional Record article publishes XML. `document_fetch_failed`: www.congress.gov did not return a readable document — a non-2xx status, a network failure, an empty body, or a content type that is not text or XML. `document_too_large`: The document is larger than the byte ceiling this server retrieves, so no character window can be served from it. `offset_past_end`: characterOffset is at or beyond the last character of every text the call would window — the document on 'content', or every returned row's summary text on 'summaries' — so the window would be empty. Other values are possible when a failure originates below the handler."
- Changed
congressgov_daily_record1 field changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `not_found`: A requested bill, member, committee, report, vote, or nomination does not exist in Congress.gov. `rate_limited`: The Congress.gov API rate limit (5,000 requests/hour per key) was exceeded. `invalid_request`: Congress.gov rejected the request as malformed — a bad date range or an identifier with an unexpected shape. `upstream_error`: Congress.gov returned an unexpected error (5xx or another non-2xx status). `document_unavailable`: The 'content' selection resolves to no retrievable document — the text version or article index is past the end of the list, the record publishes no formats at all, or Congress.gov does not hold the file its own metadata names. `format_unavailable`: The document exists but publishes nothing in the requested 'format' — some text versions and committee reports ship PDF only, and no Congressional Record article publishes XML. `document_fetch_failed`: www.congress.gov did not return a readable document — a non-2xx status, a network failure, an empty body, or a content type that is not text or XML. `document_too_large`: The document is larger than the byte ceiling this server retrieves, so no character window can be served from it. `offset_past_end`: characterOffset is at or beyond the last character of the document, so the window would be empty. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `not_found`: A requested bill, member, committee, report, vote, or nomination does not exist in Congress.gov. `rate_limited`: The Congress.gov API rate limit (5,000 requests/hour per key) was exceeded. `invalid_request`: Congress.gov rejected the request as malformed — a bad date range or an identifier with an unexpected shape. `upstream_error`: Congress.gov returned an unexpected error (5xx or another non-2xx status). `document_unavailable`: The 'content' selection resolves to no retrievable document — the text version or article index is past the end of the list, the record publishes no formats at all, or Congress.gov does not hold the file its own metadata names. `format_unavailable`: The document exists but publishes nothing in the requested 'format' — some text versions and committee reports ship PDF only, and no Congressional Record article publishes XML. `document_fetch_failed`: www.congress.gov did not return a readable document — a non-2xx status, a network failure, an empty body, or a content type that is not text or XML. `document_too_large`: The document is larger than the byte ceiling this server retrieves, so no character window can be served from it. `offset_past_end`: characterOffset is at or beyond the last character of every text the call would window — the document on 'content', or every returned row's summary text on 'summaries' — so the window would be empty. Other values are possible when a failure originates below the handler."
9 tool updates
- Changed
congressgov_bill_lookup2 fields changed- added
Output schema / properties / billAdded value: +{ + "additionalProperties": {}, + "description": "Dynamic upstream JSON record.", + "properties": {}, + "type": "object" +} - added
Output schema / properties / contentAdded value: +{ + "additionalProperties": {}, + "description": "Dynamic upstream JSON record.", + "properties": {}, + "type": "object" +}
- Changed
congressgov_committee_lookup2 fields changed- changed
Input schema / properties / filter / descriptionPrevious value: -"Filter committee list results by name (e.g., 'transportation', 'armed services'). Only meaningful for 'list'. Fetches the full chamber set and matches client-side; fuzzy-matched rows are labeled approximate."New value: +"Filter committee-list results by name (e.g., 'transportation', 'armed services'). Only meaningful for 'list'; fuzzy-matched rows are labeled approximate." - added
Output schema / properties / committeeAdded value: +{ + "additionalProperties": {}, + "description": "Dynamic upstream JSON record.", + "properties": {}, + "type": "object" +}
- Changed
congressgov_committee_reports3 fields changed- added
Output schema / properties / contentAdded value: +{ + "additionalProperties": {}, + "description": "Dynamic upstream JSON record.", + "properties": {}, + "type": "object" +} - added
Output schema / properties / reportAdded value: +{ + "additionalProperties": {}, + "description": "Dynamic upstream JSON record.", + "properties": {}, + "type": "object" +} - added
Output schema / properties / textAdded value: +{ + "description": "Dynamic upstream JSON records.", + "items": { + "additionalProperties": {}, + "description": "Dynamic upstream JSON record.", + "properties": {}, + "type": "object" + }, + "type": "array" +}
- Changed
congressgov_crs_reports1 field changed- added
Output schema / properties / reportAdded value: +{ + "additionalProperties": {}, + "description": "Dynamic upstream JSON record.", + "properties": {}, + "type": "object" +}
- Changed
congressgov_daily_record1 field changed- added
Output schema / properties / contentAdded value: +{ + "additionalProperties": {}, + "description": "Dynamic upstream JSON record.", + "properties": {}, + "type": "object" +}
- Changed
congressgov_enacted_laws1 field changed- added
Output schema / properties / lawAdded value: +{ + "additionalProperties": {}, + "description": "Dynamic upstream JSON record.", + "properties": {}, + "type": "object" +}
- Changed
congressgov_member_lookup5 fields changed- added
Input schema / properties / bioguideId / patternAdded value: +"^[A-Za-z]\\d{6}$" - removed
Input schema / properties / stateCode / maxLengthRemoved value: -2 - removed
Input schema / properties / stateCode / minLengthRemoved value: -2 - added
Input schema / properties / stateCode / patternAdded value: +"^[A-Za-z]{2}$" - added
Output schema / properties / memberAdded value: +{ + "additionalProperties": {}, + "description": "Dynamic upstream JSON record.", + "properties": {}, + "type": "object" +}
- Changed
congressgov_roll_votes1 field changed- added
Output schema / properties / voteAdded value: +{ + "additionalProperties": {}, + "description": "Dynamic upstream JSON record.", + "properties": {}, + "type": "object" +}
- Changed
congressgov_senate_nominations1 field changed- added
Output schema / properties / nominationAdded value: +{ + "additionalProperties": {}, + "description": "Dynamic upstream JSON record.", + "properties": {}, + "type": "object" +}
10 tool updates
- Changed
congressgov_bill_lookup6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "effectiveQuery", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: A requested bill, member, committee, report, vote, or nomination does not exist in Congress.gov. `rate_limited`: The Congress.gov API rate limit (5,000 requests/hour per key) was exceeded. `invalid_request`: Congress.gov rejected the request as malformed — a bad date range or an identifier with an unexpected shape. `upstream_error`: Congress.gov returned an unexpected error (5xx or another non-2xx status). `document_unavailable`: The 'content' selection resolves to no retrievable document — the text version or article index is past the end of the list, the record publishes no formats at all, or Congress.gov does not hold the file its own metadata names. `format_unavailable`: The document exists but publishes nothing in the requested 'format' — some text versions and committee reports ship PDF only, and no Congressional Record article publishes XML. `document_fetch_failed`: www.congress.gov did not return a readable document — a non-2xx status, a network failure, an empty body, or a content type that is not text or XML. `document_too_large`: The document is larger than the byte ceiling this server retrieves, so no character window can be served from it. `offset_past_end`: characterOffset is at or beyond the last character of the document, so the window would be empty. Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "rate_limited", + "invalid_request", + "upstream_error", + "document_unavailable", + "format_unavailable", + "document_fetch_failed", + "document_too_large", + "offset_past_end" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "effectiveQuery", - "totalCount" -]
- Changed
congressgov_bill_summaries6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "data", + "pagination", + "effectiveQuery", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: A requested bill, member, committee, report, vote, or nomination does not exist in Congress.gov. `rate_limited`: The Congress.gov API rate limit (5,000 requests/hour per key) was exceeded. `invalid_request`: Congress.gov rejected the request as malformed — a bad date range or an identifier with an unexpected shape. `upstream_error`: Congress.gov returned an unexpected error (5xx or another non-2xx status). Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "rate_limited", + "invalid_request", + "upstream_error" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "data", - "pagination", - "effectiveQuery", - "totalCount" -]
- Changed
congressgov_committee_lookup6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "effectiveQuery", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: A requested bill, member, committee, report, vote, or nomination does not exist in Congress.gov. `rate_limited`: The Congress.gov API rate limit (5,000 requests/hour per key) was exceeded. `invalid_request`: Congress.gov rejected the request as malformed — a bad date range or an identifier with an unexpected shape. `upstream_error`: Congress.gov returned an unexpected error (5xx or another non-2xx status). Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "rate_limited", + "invalid_request", + "upstream_error" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "effectiveQuery", - "totalCount" -]
- Changed
congressgov_committee_reports6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "effectiveQuery", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: A requested bill, member, committee, report, vote, or nomination does not exist in Congress.gov. `rate_limited`: The Congress.gov API rate limit (5,000 requests/hour per key) was exceeded. `invalid_request`: Congress.gov rejected the request as malformed — a bad date range or an identifier with an unexpected shape. `upstream_error`: Congress.gov returned an unexpected error (5xx or another non-2xx status). `document_unavailable`: The 'content' selection resolves to no retrievable document — the text version or article index is past the end of the list, the record publishes no formats at all, or Congress.gov does not hold the file its own metadata names. `format_unavailable`: The document exists but publishes nothing in the requested 'format' — some text versions and committee reports ship PDF only, and no Congressional Record article publishes XML. `document_fetch_failed`: www.congress.gov did not return a readable document — a non-2xx status, a network failure, an empty body, or a content type that is not text or XML. `document_too_large`: The document is larger than the byte ceiling this server retrieves, so no character window can be served from it. `offset_past_end`: characterOffset is at or beyond the last character of the document, so the window would be empty. Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "rate_limited", + "invalid_request", + "upstream_error", + "document_unavailable", + "format_unavailable", + "document_fetch_failed", + "document_too_large", + "offset_past_end" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "effectiveQuery", - "totalCount" -]
- Changed
congressgov_crs_reports6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "effectiveQuery", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: A requested bill, member, committee, report, vote, or nomination does not exist in Congress.gov. `rate_limited`: The Congress.gov API rate limit (5,000 requests/hour per key) was exceeded. `invalid_request`: Congress.gov rejected the request as malformed — a bad date range or an identifier with an unexpected shape. `upstream_error`: Congress.gov returned an unexpected error (5xx or another non-2xx status). Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "rate_limited", + "invalid_request", + "upstream_error" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "effectiveQuery", - "totalCount" -]
- Changed
congressgov_daily_record6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "effectiveQuery", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: A requested bill, member, committee, report, vote, or nomination does not exist in Congress.gov. `rate_limited`: The Congress.gov API rate limit (5,000 requests/hour per key) was exceeded. `invalid_request`: Congress.gov rejected the request as malformed — a bad date range or an identifier with an unexpected shape. `upstream_error`: Congress.gov returned an unexpected error (5xx or another non-2xx status). `document_unavailable`: The 'content' selection resolves to no retrievable document — the text version or article index is past the end of the list, the record publishes no formats at all, or Congress.gov does not hold the file its own metadata names. `format_unavailable`: The document exists but publishes nothing in the requested 'format' — some text versions and committee reports ship PDF only, and no Congressional Record article publishes XML. `document_fetch_failed`: www.congress.gov did not return a readable document — a non-2xx status, a network failure, an empty body, or a content type that is not text or XML. `document_too_large`: The document is larger than the byte ceiling this server retrieves, so no character window can be served from it. `offset_past_end`: characterOffset is at or beyond the last character of the document, so the window would be empty. Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "rate_limited", + "invalid_request", + "upstream_error", + "document_unavailable", + "format_unavailable", + "document_fetch_failed", + "document_too_large", + "offset_past_end" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "effectiveQuery", - "totalCount" -]
- Changed
congressgov_enacted_laws6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "effectiveQuery", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: A requested bill, member, committee, report, vote, or nomination does not exist in Congress.gov. `rate_limited`: The Congress.gov API rate limit (5,000 requests/hour per key) was exceeded. `invalid_request`: Congress.gov rejected the request as malformed — a bad date range or an identifier with an unexpected shape. `upstream_error`: Congress.gov returned an unexpected error (5xx or another non-2xx status). Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "rate_limited", + "invalid_request", + "upstream_error" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "effectiveQuery", - "totalCount" -]
- Changed
congressgov_member_lookup6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "effectiveQuery", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: A requested bill, member, committee, report, vote, or nomination does not exist in Congress.gov. `rate_limited`: The Congress.gov API rate limit (5,000 requests/hour per key) was exceeded. `invalid_request`: Congress.gov rejected the request as malformed — a bad date range or an identifier with an unexpected shape. `upstream_error`: Congress.gov returned an unexpected error (5xx or another non-2xx status). Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "rate_limited", + "invalid_request", + "upstream_error" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "effectiveQuery", - "totalCount" -]
- Changed
congressgov_roll_votes6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "effectiveQuery", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: A requested bill, member, committee, report, vote, or nomination does not exist in Congress.gov. `rate_limited`: The Congress.gov API rate limit (5,000 requests/hour per key) was exceeded. `invalid_request`: Congress.gov rejected the request as malformed — a bad date range or an identifier with an unexpected shape. `upstream_error`: Congress.gov returned an unexpected error (5xx or another non-2xx status). Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "rate_limited", + "invalid_request", + "upstream_error" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "effectiveQuery", - "totalCount" -]
- Changed
congressgov_senate_nominations6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "effectiveQuery", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: A requested bill, member, committee, report, vote, or nomination does not exist in Congress.gov. `rate_limited`: The Congress.gov API rate limit (5,000 requests/hour per key) was exceeded. `invalid_request`: Congress.gov rejected the request as malformed — a bad date range or an identifier with an unexpected shape. `upstream_error`: Congress.gov returned an unexpected error (5xx or another non-2xx status). Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "rate_limited", + "invalid_request", + "upstream_error" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "effectiveQuery", - "totalCount" -]
5 tool updates
- Changed
congressgov_bill_lookup10 fields changed- added
Input schema / properties / billNumber / anyOfAdded value: +[ + { + "description": "Positive integer form.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + { + "description": "Digit-string form, as list rows carry it.", + "pattern": "^0*[1-9]\\d*$", + "type": "string" + } +] - changed
Input schema / properties / billNumber / descriptionPrevious value: -"Bill number. Required for get and sub-resource operations."New value: +"Bill number. Required for get and sub-resource operations. Accepts the digit-string form list rows carry (e.g. \"9479\") as well as a number." - removed
Input schema / properties / billNumber / exclusiveMinimumRemoved value: -0 - removed
Input schema / properties / billNumber / maximumRemoved value: -9007199254740991 - removed
Input schema / properties / billNumber / typeRemoved value: -"integer" - added
Input schema / properties / characterLimitAdded value: +{ + "default": 25000, + "description": "Maximum characters to return for 'content' (1-100000). Legislative documents run past a million characters, so a full bill takes several windows.", + "maximum": 100000, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / characterOffsetAdded value: +{ + "default": 0, + "description": "First 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.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / formatAdded value: +{ + "default": "text", + "description": "Document 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.", + "enum": [ + "text", + "xml" + ], + "type": "string" +} - changed
Input schema / properties / operation / enumPrevious value: -[ - "list", - "get", - "actions", - "amendments", - "cosponsors", - "committees", - "subjects", - "summaries", - "text", - "titles", - "related" -]New value: +[ + "list", + "get", + "actions", + "amendments", + "cosponsors", + "committees", + "subjects", + "summaries", + "text", + "titles", + "related", + "content" +] - added
Input schema / properties / textVersionIndexAdded value: +{ + "default": 0, + "description": "Which text version 'content' reads, 0-based against the same order 'text' returns — 0 is the most recent version. Ignored by other operations.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +}
- Changed
congressgov_committee_lookup2 fields changed- changed
Input schema / properties / committeeCode / descriptionPrevious value: -"Committee system code, e.g. 'hsju00'. Required for 'get' and sub-resources. Codes are lowercase letters + 2-digit suffix. Pass a committee name here and the tool will attempt to resolve it automatically — or use operation:'list' with filter to browse."New value: +"Committee system code, e.g. 'hsju00'. Required for 'get' and sub-resources. Codes are letters + a 2-digit suffix and are matched case-insensitively. Any other non-blank value is treated as a committee name and resolved automatically — single-word names ('Judiciary') included — or use operation:'list' with filter to browse." - changed
Input schema / properties / committeeCode / patternPrevious value: -"^([a-z]{2,6}\\d{2}|.*\\s.*)$"New value: +"\\S"
- Changed
congressgov_committee_reports6 fields changed- added
Input schema / properties / characterLimitAdded value: +{ + "default": 25000, + "description": "Maximum characters to return for 'content' (1-100000). Legislative documents run past a million characters, so a full bill takes several windows.", + "maximum": 100000, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / characterOffsetAdded value: +{ + "default": 0, + "description": "First 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.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / formatAdded value: +{ + "default": "text", + "description": "Document 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.", + "enum": [ + "text", + "xml" + ], + "type": "string" +} - changed
Input schema / properties / operation / enumPrevious value: -[ - "list", - "get", - "text" -]New value: +[ + "list", + "get", + "text", + "content" +] - changed
Input schema / properties / reportNumber / descriptionPrevious value: -"Committee report number. Required for get and text operations."New value: +"Committee report number. Required for get, text, and content operations." - changed
Input schema / properties / reportType / descriptionPrevious value: -"Report type. Required for get and text operations."New value: +"Report type. Required for get, text, and content operations."
- Changed
congressgov_daily_record16 fields changed- added
Input schema / properties / articleIndexAdded value: +{ + "default": 0, + "description": "Which article 'content' reads, 0-based against the issue's whole article sequence — the same absolute position 'articles' pages through with offset. Ignored by other operations.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / characterLimitAdded value: +{ + "default": 25000, + "description": "Maximum characters to return for 'content' (1-100000). Legislative documents run past a million characters, so a full bill takes several windows.", + "maximum": 100000, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / characterOffsetAdded value: +{ + "default": 0, + "description": "First 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.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / formatAdded value: +{ + "default": "text", + "description": "Document 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.", + "enum": [ + "text", + "xml" + ], + "type": "string" +} - added
Input schema / properties / issueNumber / anyOfAdded value: +[ + { + "description": "Positive integer form.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + { + "description": "Digit-string form, as list rows carry it.", + "pattern": "^0*[1-9]\\d*$", + "type": "string" + } +] - changed
Input schema / properties / issueNumber / descriptionPrevious value: -"Issue number within a volume. Required for 'articles'."New value: +"Issue number within a volume. Required for 'articles' and 'content'. List rows carry this as a string (e.g. \"109\") — both forms are accepted." - removed
Input schema / properties / issueNumber / exclusiveMinimumRemoved value: -0 - removed
Input schema / properties / issueNumber / maximumRemoved value: -9007199254740991 - removed
Input schema / properties / issueNumber / typeRemoved value: -"integer" - changed
Input schema / properties / operation / enumPrevious value: -[ - "list", - "issues", - "articles" -]New value: +[ + "list", + "issues", + "articles", + "content" +] - added
Input schema / properties / volumeNumber / anyOfAdded value: +[ + { + "description": "Positive integer form.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + { + "description": "Digit-string form, as list rows carry it.", + "pattern": "^0*[1-9]\\d*$", + "type": "string" + } +] - changed
Input schema / properties / volumeNumber / descriptionPrevious value: -"Volume number. Required for 'issues' and 'articles'."New value: +"Volume number. Required for 'issues', 'articles', and 'content'. Accepts a number or the digit-string form list rows carry." - removed
Input schema / properties / volumeNumber / exclusiveMinimumRemoved value: -0 - removed
Input schema / properties / volumeNumber / maximumRemoved value: -9007199254740991 - removed
Input schema / properties / volumeNumber / typeRemoved value: -"integer" - changed
Output schema / requiredPrevious value: -[ - "data", - "pagination", - "effectiveQuery", - "totalCount" -]New value: +[ + "effectiveQuery", + "totalCount" +]
- Changed
congressgov_enacted_laws5 fields changed- added
Input schema / properties / lawNumber / anyOfAdded value: +[ + { + "description": "Positive integer form (e.g. 90).", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + { + "description": "String form — the law number (\"90\") or the full citation (\"118-90\").", + "pattern": "^(?:\\d+-)?0*[1-9]\\d*$", + "type": "string" + } +] - changed
Input schema / properties / lawNumber / descriptionPrevious value: -"Law number. Required for 'get'."New value: +"Law number, as carried by a 'list' row's `laws[].number` — either the full citation ('118-90', rendered as 'Public Law 118-90') or the portion after the hyphen ('90'); the prefix is the congress and must match `congress`. Not the row's own `number`, which is the origin bill. Required for 'get'." - removed
Input schema / properties / lawNumber / exclusiveMinimumRemoved value: -0 - removed
Input schema / properties / lawNumber / maximumRemoved value: -9007199254740991 - removed
Input schema / properties / lawNumber / typeRemoved value: -"integer"
1 tool update
- Changed
congressgov_committee_lookup2 fields changed- changed
Input schema / properties / committeeCode / descriptionPrevious value: -"Committee system code (e.g., 'hsju00'). Required for get and sub-resources."New value: +"Committee system code, e.g. 'hsju00'. Required for 'get' and sub-resources. Codes are lowercase letters + 2-digit suffix. Pass a committee name here and the tool will attempt to resolve it automatically — or use operation:'list' with filter to browse." - added
Input schema / properties / committeeCode / patternAdded value: +"^([a-z]{2,6}\\d{2}|.*\\s.*)$"
2 tool updates
- Changed
congressgov_committee_lookup1 field changed- added
Input schema / properties / filterAdded value: +{ + "description": "Filter committee list results by name (e.g., 'transportation', 'armed services'). Only meaningful for 'list'. Fetches the full chamber set and matches client-side; fuzzy-matched rows are labeled approximate.", + "type": "string" +}
- Changed
congressgov_roll_votes2 fields changed- added
Input schema / properties / chamberAdded value: +{ + "default": "house", + "description": "Chamber whose votes to query. 'house' (default) draws from the Congress.gov API; 'senate' draws from the Senate's official LIS roll-call feed. Roll call numbers reset each session and are specific to one chamber.", + "enum": [ + "house", + "senate" + ], + "type": "string" +} - changed
Input schema / properties / order / descriptionPrevious value: -"Sort order for 'list', by vote update date. 'recent' (default) returns newest first; 'oldest' returns ascending. With 'recent', offset=0 always returns the strictly newest page. Ignored by 'get' and 'members'."New value: +"Sort order for 'list'. 'recent' (default) returns newest first; 'oldest' returns ascending. House sorts by vote update date (with 'recent', offset=0 always returns the strictly newest page); Senate sorts by roll call number. Ignored by 'get' and 'members'."
10 tool updates
- Changed
congressgov_bill_lookup6 fields changed- removed
Output schema / descriptionRemoved value: -"Detail-mode key 'bill' carries: Bill record (sponsor, policy area, latest action, CBO estimates, law citation) for `get`; absent for `list` and sub-resources." - added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "The browse scope and applied filters.", + "type": "string" +} - added
Output schema / properties / noticeAdded value: +{ + "description": "Guidance when results are empty, a page is past the end, or a caveat applies.", + "type": "string" +} - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echo of the applied filters for list-mode queries. Rendered as the first line of the response.", - "type": "string" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Total results across all pages.", + "type": "number" +} - added
Output schema / requiredAdded value: +[ + "effectiveQuery", + "totalCount" +]
- Changed
congressgov_bill_summaries5 fields changed- added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "The browse scope and applied filters.", + "type": "string" +} - added
Output schema / properties / noticeAdded value: +{ + "description": "Guidance when results are empty, a page is past the end, or a caveat applies.", + "type": "string" +} - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echo of the applied filters for this query. Rendered as the first line of the response so the caller can confirm what was searched.", - "type": "string" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Total results across all pages.", + "type": "number" +} - changed
Output schema / requiredPrevious value: -[ - "data", - "pagination" -]New value: +[ + "data", + "pagination", + "effectiveQuery", + "totalCount" +]
- Changed
congressgov_committee_lookup6 fields changed- removed
Output schema / descriptionRemoved value: -"Detail-mode key 'committee' carries: Committee record for `get` (name, chamber, subcommittees, history, sub-resource counts); absent for `list` and sub-resources." - added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "The browse scope and applied filters.", + "type": "string" +} - added
Output schema / properties / noticeAdded value: +{ + "description": "Guidance when results are empty, a page is past the end, or a caveat applies.", + "type": "string" +} - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echo of the applied filters for list-mode queries. Rendered as the first line of the response.", - "type": "string" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Total results across all pages.", + "type": "number" +} - added
Output schema / requiredAdded value: +[ + "effectiveQuery", + "totalCount" +]
- Changed
congressgov_committee_reports6 fields changed- removed
Output schema / descriptionRemoved value: -"Detail-mode key 'report' carries: the committee report (citation, title, committees, associated bill); for `text`, an alternative key 'text' carries an array of {type, url} format links." - added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "The browse scope and applied filters.", + "type": "string" +} - added
Output schema / properties / noticeAdded value: +{ + "description": "Guidance when results are empty, a page is past the end, or a caveat applies.", + "type": "string" +} - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echo of the applied filters for list-mode queries. Rendered as the first line of the response.", - "type": "string" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Total results across all pages.", + "type": "number" +} - added
Output schema / requiredAdded value: +[ + "effectiveQuery", + "totalCount" +]
- Changed
congressgov_crs_reports6 fields changed- removed
Output schema / descriptionRemoved value: -"Detail-mode key 'report' carries: CRS report record for `get` (authors, topics, summary, formats, related materials); absent for `list`." - added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "The browse scope and applied filters.", + "type": "string" +} - added
Output schema / properties / noticeAdded value: +{ + "description": "Guidance when results are empty, a page is past the end, or a caveat applies.", + "type": "string" +} - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echo of the applied filters for list-mode queries. Rendered as the first line of the response.", - "type": "string" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Total results across all pages.", + "type": "number" +} - added
Output schema / requiredAdded value: +[ + "effectiveQuery", + "totalCount" +]
- Changed
congressgov_daily_record5 fields changed- added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "The browse scope and applied filters.", + "type": "string" +} - added
Output schema / properties / noticeAdded value: +{ + "description": "Guidance when results are empty, a page is past the end, or a caveat applies.", + "type": "string" +} - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echo of the applied filters for this query. Rendered as the first line of the response so the caller can confirm what was searched.", - "type": "string" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Total results across all pages.", + "type": "number" +} - changed
Output schema / requiredPrevious value: -[ - "data", - "pagination" -]New value: +[ + "data", + "pagination", + "effectiveQuery", + "totalCount" +]
- Changed
congressgov_enacted_laws6 fields changed- removed
Output schema / descriptionRemoved value: -"Detail-mode key 'law' carries: Origin bill record for `get`; absent for `list`. The bill's `laws` array carries the law citation." - added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "The browse scope and applied filters.", + "type": "string" +} - added
Output schema / properties / noticeAdded value: +{ + "description": "Guidance when results are empty, a page is past the end, or a caveat applies.", + "type": "string" +} - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echo of the applied filters for list-mode queries. Rendered as the first line of the response.", - "type": "string" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Total results across all pages.", + "type": "number" +} - added
Output schema / requiredAdded value: +[ + "effectiveQuery", + "totalCount" +]
- Changed
congressgov_member_lookup6 fields changed- removed
Output schema / descriptionRemoved value: -"Detail-mode key 'member' carries: Member profile for `get` (name, state, terms, party history, leadership, legislation counts); absent for `list`, `sponsored`, `cosponsored`." - added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "The browse scope and applied filters.", + "type": "string" +} - added
Output schema / properties / noticeAdded value: +{ + "description": "Guidance when results are empty, a page is past the end, or a caveat applies.", + "type": "string" +} - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echo of the applied filters for list-mode queries. Rendered as the first line of the response.", - "type": "string" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Total results across all pages.", + "type": "number" +} - added
Output schema / requiredAdded value: +[ + "effectiveQuery", + "totalCount" +]
- Changed
congressgov_roll_votes6 fields changed- removed
Output schema / descriptionRemoved value: -"Detail-mode key 'vote' carries: Vote record for `get` and `members` (question, result, party totals, member positions); absent for `list`." - added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "The browse scope and applied filters.", + "type": "string" +} - added
Output schema / properties / noticeAdded value: +{ + "description": "Guidance when results are empty, a page is past the end, or a caveat applies.", + "type": "string" +} - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echo of the applied filters for list-mode queries. Rendered as the first line of the response.", - "type": "string" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Total results across all pages.", + "type": "number" +} - added
Output schema / requiredAdded value: +[ + "effectiveQuery", + "totalCount" +]
- Changed
congressgov_senate_nominations6 fields changed- removed
Output schema / descriptionRemoved value: -"Detail-mode key 'nomination' carries: Nomination record for `get` (description, dates, nominees array, sub-resource counts); absent for `list` and sub-resources." - added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "The browse scope and applied filters.", + "type": "string" +} - added
Output schema / properties / noticeAdded value: +{ + "description": "Guidance when results are empty, a page is past the end, or a caveat applies.", + "type": "string" +} - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echo of the applied filters for list-mode queries. Rendered as the first line of the response.", - "type": "string" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Total results across all pages.", + "type": "number" +} - added
Output schema / requiredAdded value: +[ + "effectiveQuery", + "totalCount" +]
Related MCP Connectors
Congress MCP — US Congress data via GovTrack API (free, no auth required)
GovTrack MCP — federal US Congress data (free, no auth)
LegiScan MCP — wraps the LegiScan API (api.legiscan.com)
An MCP server that provides congressional transcripts
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables querying U.S. legislative data from Congress.gov API using MCP resources for direct lookups and tools for searching and retrieving related data.8MIT
- AlicenseAqualityAmaintenanceRemote MCP server for nonpartisan U.S. Congress data: plain-language bill decodes (bilingual EN/ES), representative lookup by ZIP with district-office phones, and what's-moving urgency ranking. Read-only, keyless.51AGPL 3.0
- AlicenseNot gradedqualityCmaintenanceEnables querying legislative data from the LegiScan API, including bills and votes, via natural language through an MCP gateway.2 npmMIT
- AlicenseAqualityAmaintenanceMCP server for the Congress.gov API that tracks US federal legislative process, providing tools to search bills and get bill details.1138 PyPI1Apache 2.0
Glama MCP Gateway
Add one secure layer between your agents and this server.