Skip to main content
Glama
cliwant

mcp-sam-gov

by cliwant

congress_search_bills

Read-only

Search and filter legislation bills from Congress.gov by congress, bill type, and date range. Returns bill details with pagination.

Instructions

Search Congress.gov BILLS/legislation (api.data.gov keyed; DATA_GOV_API_KEY or DEMO_KEY). Input optional congress (e.g. 118), billType (hr/s/hjres/sjres/hconres/sconres/hres/sres — requires congress), fromDateTime/toDateTime (ISO-8601 with offset), offset, limit (≤250, def 20). Returns { bills:[{ congress, type, number, title, originChamber, latestAction, updateDate, url }] } + _meta with totalAvailable = pagination.count (EXACT). NOTE: /v3/bill has no keyword search, so a query arg is NOT applied and is disclosed in _meta.filtersDropped. Outage/4xx THROWS (never a fake empty).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoRecords per page, 1..250, default 20.
queryNoKeyword — NOTE: Congress.gov /v3/bill has NO keyword search, so this is NOT applied (disclosed in _meta.filtersDropped). Use congress/billType/date filters instead.
offsetNo0-based record offset for pagination, default 0.
billTypeNoBill type: hr/s/hjres/sjres/hconres/sconres/hres/sres. Requires `congress` (path /v3/bill/{congress}/{billType}).
congressNoCongress number, e.g. 118 (scopes the path to /v3/bill/{congress}).
toDateTimeNoFilter to bills updated at/before this ISO-8601 date-time with offset, e.g. '2024-12-31T23:59:59Z'.
fromDateTimeNoFilter to bills updated at/after this ISO-8601 date-time with offset, e.g. '2024-01-01T00:00:00Z'.
Behavior5/5

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

Beyond annotations (readOnlyHint, openWorldHint), the description adds key behavioral details: API key requirement, that outages/4xx throw errors (never fake empty), and that query parameter is dropped. No contradictions 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.

Conciseness4/5

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

The description is dense with information but remains single-paragraph and front-loaded with the main purpose. While efficient, a bit more structure (e.g., bullet points) could improve readability, but it is not overly long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description thoroughly details the return format (bills array with fields + meta with totalAvailable) and error behavior (throws on outage/4xx). Also covers all parameters, key requirement, and pagination. Complete for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant value beyond schema: explains query is not applied, billType requires congress, ISO-8601 date format examples, limit max 250, default 20, and return structure. This fully compensates and enhances understanding.

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

Purpose5/5

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

The description clearly states it is for searching Congress.gov BILLS/legislation, specifying the resource (bills) and action (search). It also distinguishes from potential siblings (like congress_get_bill) by focusing on list/search functionality and noting limitations like no keyword search.

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

Usage Guidelines4/5

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

The description provides guidance on parameter usage, such as requiring congress for billType, explaining that query is not applied and suggesting alternatives (congress/billType/date filters). However, it does not explicitly mention when to use sibling tools like congress_get_bill for single bills.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cliwant/mcp-sam-gov'

If you have feedback or need assistance with the MCP directory API, please join our Discord server