congressgov-mcp-server
Server Details
Access U.S. congressional data - bills, votes, members, committees - via MCP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/congressgov-mcp-server
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 10 of 10 tools scored.
Tools are generally distinct by domain, but there is overlap: 'bill_lookup' includes a 'summaries' operation while a separate 'bill_summaries' tool exists for browsing summaries across bills. Similarly, 'committee_lookup' has a 'reports' sub-resource alongside a dedicated 'committee_reports' tool. These redundancies could cause agents to select the wrong tool despite descriptive clarifications.
All tools share the 'congressgov_' prefix and use a consistent noun-based naming pattern (e.g., bill_lookup, committee_reports). While not strictly verb_noun, the convention is uniform and predictable. Minor deviation: 'roll_votes' uses plural noun; others singular. Overall strong consistency.
With 10 tools covering bills, committees, members, votes, nominations, CRS reports, daily record, and enacted laws, the count is well-scoped for the Congress.gov domain. Each tool addresses a distinct major aspect without being overly granular or sparse.
The tool set covers core legislative data surfaces: bills, committees, members, votes, nominations, and reports. However, notable gaps include lack of treaty or hearing information, and limited search capabilities (no keyword search across bills). Minor gaps that agents can often work around.
Available Tools
10 toolscongressgov_bill_lookupCongressgov 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).
| 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 |
| 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. | |
| toDateTime | No | End of date range filter (ISO 8601). Same field semantics as fromDateTime. | |
| 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Result rows. Per-tool item shape is rendered in the markdown body. |
| 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 | Yes | Total results across all pages. |
| effectiveQuery | Yes | The browse scope and applied filters. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds behavioral details like default sort order ('most-recently-updated first') and date range filter semantics (update date, not legislative action). No contradictions.
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 a single well-structured paragraph that front-loads the main purpose, then explains operations and parameter context. No wasted words; every sentence provides value.
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 (9 parameters, multiple operations, output schema present), the description adequately covers usage scenarios, defaults, and limitations. It lacks details on response structure but the output schema fills that gap.
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% (baseline 3). The description adds meaning beyond the schema by explaining operation-specific required parameters and clarifying the date range filter's effect on update date, which helps the agent correctly use the tool.
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's purpose: browse and retrieve U.S. legislative bill data. It lists specific operations (list, get, sub-resources) and filtering options. While it doesn't explicitly differentiate from sibling tools, the operation list implies scope, leaving some ambiguity.
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 explains when to use each operation (e.g., 'list' to browse, 'get' for full detail) and notes the lack of keyword search. It provides clear context but does not compare directly to sibling tools like congressgov_bill_summaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_bill_summariesCongressgov 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. For summaries of one specific bill, 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 | Yes | Result rows. Per-tool item shape is rendered in the markdown body. |
| notice | No | Guidance when results are empty, a page is past the end, or a caveat applies. |
| pagination | Yes | Pagination metadata: total count and next offset. |
| totalCount | Yes | Total results across all pages. |
| effectiveQuery | Yes | The browse scope and applied filters. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. Description adds nuance about date filters affecting summary update time, not bill action date, and default 7-day window.
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?
Concise, front-loaded with purpose. Every sentence adds value without redundancy.
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?
Output schema exists, so return format is covered. Description fully explains key behaviors, defaults, and alternatives.
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% (baseline 3). Description adds meaning beyond schema by explaining date filters apply to update time and default behavior when neither date is set.
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 CRS bill summaries and explicitly contrasts with congressgov_bill_lookup for single-bill summaries.
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?
Provides explicit when-to-use ('what's happening in Congress'), details on date filter semantics, and when-not-to: use congressgov_bill_lookup for a specific bill's summaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_committee_lookupCongressgov 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'. Fetches the full chamber set and matches client-side; 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 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Result rows. Per-tool item shape is rendered in the markdown body. |
| 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 | Yes | Total results across all pages. |
| effectiveQuery | Yes | The browse scope and applied filters. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, open-world, and idempotent. The description adds useful behavioral context: default ordering for 'bills', upstream omission of bill titles, chamber inference from committee code, and client-side fuzzy matching for filter. 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?
The description is detailed but well-structured, front-loading the main purpose and then systematically explaining operations, codes, and limitations. Every sentence adds value, though it could be slightly more concise for a 1-5 scale.
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 (8 parameters, multiple operations, sub-resources, code patterns, missing titles), the description is complete. It explains the workflow, parameter interactions, and limitations. Since an output schema exists, return value details are not required.
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% but the description adds significant meaning beyond the schema: clarifies committeeCode can auto-resolve names, explains the code pattern, details order behavior, and describes filter as client-side with fuzzy matching. This goes well beyond the schema descriptions.
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 congressional committees and their legislation, reports, and nominations. It specifies the resource and operations, distinguishing it from sibling tools like congressgov_bill_lookup.
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?
Provides explicit guidance on when to use each operation (list/get/bills/reports/nominations), how to discover committee codes, and notes that nominations are Senate-only. Also recommends chaining to congressgov_bill_lookup for missing bill titles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_committee_reportsCongressgov 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).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1-250). | |
| offset | No | Pagination offset. | |
| congress | Yes | Congress number. | |
| operation | Yes | Which data to retrieve. | |
| reportType | No | Report type. Required for get and text operations. | |
| reportNumber | No | Committee report number. Required for get and text operations. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Result rows. Per-tool item shape is rendered in the markdown body. |
| 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 | Yes | Total results across all pages. |
| effectiveQuery | Yes | The browse scope and applied filters. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description aligns with these (e.g., 'retrieve' suggests read-only) and adds context about the content of reports. No contradictions or additional needed behavioral details.
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?
Two sentences that are front-loaded with the action and purpose, followed by relevant context. No wasted words.
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 comprehensive annotations, full schema coverage, and existence of an output schema, the description adequately explains what the tool returns and the general purpose. It covers all necessary context for an agent.
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% with descriptions for all parameters. The description mentions report types but adds no new parameter semantics beyond the schema. Baseline 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 clearly states the verb 'browse and retrieve', identifies the resource 'committee reports', and explains their purpose and types (hrpt, srpt, erpt). This distinguishes it from siblings like congressgov_committee_lookup.
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 implies when to use the tool (to retrieve committee reports) but provides no explicit guidance on when not to use it or which sibling tools to use instead for related tasks like bill summaries or CRS reports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_crs_reportsCongressgov 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. |
| 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 | Yes | Total results across all pages. |
| effectiveQuery | Yes | The browse scope and applied filters. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds context: reports are nonpartisan, by subject-matter experts, covering policy areas and legal questions, and IDs use letter-number codes. No contradictions; adds value beyond 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?
Two sentences: first introduces the tool and its content, second provides usage guidance and ID examples. Information is front-loaded. No redundant sentences. Could be slightly more compact, but still efficient.
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 input schema is fully described (100% coverage) and an output schema exists (not shown but present), the description covers the essential: purpose, content type, and operation distinction. No missing critical information for an agent to select and invoke the tool.
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 covers all 4 parameters with descriptions (100% coverage). The description adds meaning by explaining report ID format with examples (e.g., R40097) and specifying that 'reportNumber' is required for 'get', and that 'list' and 'get' are the operations. This helps the agent understand usage beyond 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?
Clearly states the tool browses and retrieves CRS reports, specific to Congressional Research Service analyses. Distinguishes from sibling tools (e.g., bill lookup, committee reports) by focusing exclusively on CRS documents. Verb 'Browse and retrieve' with specific resource 'CRS reports' is precise.
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?
Describes two operations ('list' to browse, 'get' for full detail) and provides examples of report IDs. Implicitly tells when to use this tool (for CRS reports) versus siblings. Could be more explicit about not using for other congressional document types, but context from sibling list makes differentiation clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_daily_recordCongressgov 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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1-250). | |
| offset | No | Pagination offset. | |
| operation | Yes | Which data to retrieve. | |
| issueNumber | No | Issue number within a volume. Required for 'articles'. | |
| volumeNumber | No | Volume number. Required for 'issues' and 'articles'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Result rows. Per-tool item shape is rendered in the markdown body. |
| notice | No | Guidance when results are empty, a page is past the end, or a caveat applies. |
| pagination | Yes | Pagination metadata: total count and next offset. |
| totalCount | Yes | Total results across all pages. |
| effectiveQuery | Yes | The browse scope and applied filters. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to reiterate safety. It adds context that data is published per session day, but no new behavioral constraints. Adequate for a read-only tool.
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?
Two sentences with no fluff. Front-loaded with purpose, then navigation pattern. Every sentence serves a clear purpose.
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 output schema exists and annotations are comprehensive, the description sufficiently covers use cases. It could mention pagination (limit/offset), but the schema handles that. Still complete enough for an AI agent.
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 description adds minor value by explaining the hierarchy. However, it does not detail parameter formats or relationships beyond what the schema provides. Baseline 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 clearly states the tool browses the Congressional Record, specifying it includes floor speeches, debates, and legislative text. It distinguishes itself from sibling tools (e.g., congressgov_bill_lookup) by focusing on the daily record.
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?
Explicitly describes the hierarchical navigation and when to use each operation (list, issues, articles). This provides clear guidance for selecting the correct operation, outperforming most tool descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_enacted_lawsCongressgov 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. Required for 'get'. | |
| operation | Yes | Which data to retrieve. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Result rows. Per-tool item shape is rendered in the markdown body. |
| 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 | Yes | Total results across all pages. |
| effectiveQuery | Yes | The browse scope and applied filters. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context: the 'get' operation returns the origin bill record with sponsor, actions, summaries, text, and the public/private law citation on the 'laws' array, with an example. This goes beyond 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 concise with two well-structured paragraphs, front-loaded with the main purpose. Every sentence adds value, including the example and the differentiation from sibling tools. No unnecessary words.
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 complexity with 6 parameters (2 required), a clear output schema, and sibling tools, the description fully covers operations, parameters, output structure (with example), and usage guidance. No gaps remain.
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% with all parameters documented. The description adds meaning by explaining the lawType enum values in more detail ('public laws, general application, most common' vs 'private laws, specific individuals or entities'), clarifying that lawNumber and lawType are required for 'get', and providing an output example.
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 'Browse enacted public and private laws from Congress.gov by congress and law type', using a specific verb and resource, and distinguishes two operations ('list' and 'get'). It also contrasts with the sibling tool bill_lookup, clearly differentiating its purpose.
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 says that 'list' filters by enactment status and law type that bill_lookup does not offer, providing a clear when-to-use vs alternative. It also implies when to use 'get' by specifying required parameters (lawNumber, lawType).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_member_lookupCongressgov 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. |
| 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 | Yes | Total results across all pages. |
| effectiveQuery | Yes | The browse scope and applied filters. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint true. Description reinforces read-only nature and adds workflow context (filtering, chaining operations). No contradiction.
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?
Two concise sentences with no wasted words. First sentence states purpose; second provides actionable usage details. Front-loaded and efficient.
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?
Description covers all critical aspects for correct invocation: operations, filter combinations, required parameters per operation, and pagination hints. Output schema exists, so return values are covered. Complete given 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?
Despite 100% schema coverage, description adds significant meaning: explains how operation values interact with filters, clarifies that bioguideId is required for certain operations, and gives examples of filter combinations.
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 is for discovering congressional members and their legislative activity. It distinguishes operations (list, get, sponsored, cosponsored) and specifies filtering criteria, avoiding tautology.
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?
Provides explicit context for when to use each operation (e.g., 'No name search', filter by stateCode/district/congress, use bioguideId for get/sponsored/cosponsored). Lacks direct comparison with sibling tools but offers strong internal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_roll_votesCongressgov 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. |
| 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 | Yes | Total results across all pages. |
| effectiveQuery | Yes | The browse scope and applied filters. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. Description adds behavioral details: pagination behavior, default sorting (newest first), and differences between House and Senate sorting. It also lists the data fields returned for 'get'. This enriches the agent's understanding beyond 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?
Description is well-structured, starting with the overall purpose and then detailing chamber and operations. Each section adds necessary information without repetition. Slightly verbose in the middle section, but still efficient for the amount of information conveyed.
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 8 parameters, 3 operations, and two data sources, the description covers the key aspects: operation modes, data source differences, and output elements for 'get'. The existence of an output schema reduces the need to describe return format. Minor omission: no mention of error handling or rate limits, but annotations provide safety guarantees.
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. Description adds value by explaining how 'order' affects House vs Senate sorting and how 'offset' works with 'recent' for the House. It also clarifies that voteNumber is required for get and members. These details go beyond the schema descriptions.
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?
Description clearly states the tool retrieves roll call votes and member voting positions, specifying both chambers. It distinguishes three operations (list, get, members) and explains what each returns, making it easy to differentiate from sibling tools (bills, summaries, etc.).
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?
Description explicitly tells when to use each operation (list, get, members) and explains the chamber parameter with its data sources. While it doesn't include explicit 'when not to use', the context is clear, and sibling tool names provide differentiation. Good guidance on operation selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congressgov_senate_nominationsCongressgov 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. |
| 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 | Yes | Total results across all pages. |
| effectiveQuery | Yes | The browse scope and applied filters. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, and idempotent hints. The description adds substantial behavioral context beyond annotations, such as PN numbering, partitioned form handling for multi-parent nominations, and the behavior of 'get' on parents without a nominees array. No contradictions.
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 front-loaded with purpose and logically structured. While dense, each sentence adds value for a complex domain. It could be slightly shorter, but the detail is warranted given the nuance of multi-part nominations.
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 (multiple operations, partitioned nominations), the description is complete. It covers all operations, numbering conventions, and edge cases. The presence of a full input schema and output schema further supports completeness.
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 significant meaning beyond the schema, especially for the ordinal parameter (explaining batch ordinals and partitioned forms) and nominationNumber (bare vs partitioned form). This is crucial for correct usage.
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's purpose: 'Browse presidential nominations to federal positions and track the Senate confirmation process.' It lists specific operations (list, get, nominees, actions, committees, hearings), immediately distinguishing it from sibling tools like bill_lookup or member_lookup.
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 when to use each operation (e.g., 'list' to browse, 'get' for detail) and explains the nuanced relationship between parent and partitioned child nominations. It lacks an explicit 'when not to use' or direct comparison to siblings, but the instructions are clear and context-specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!