congressgov-mcp-server

Congress.gov Bill Search

congressgov_search_bills

Read-onlyIdempotent

Keyword-search U.S. bills by title and CRS summary text — the discovery path the Congress.gov API itself lacks (it has no keyword search). Backed by a local full-text index over a bounded congress window; title and summary are indexed, but policy area and full bill text are not. Returns BM25-ranked matches, each with the bill's derived id (congress/billType/billNumber) for follow-up congressgov_bill_lookup calls and a truncated summary preview. Narrow with the optional congress, billType, and originChamber filters. Searches the local mirror, not the live API — if the mirror has not finished its initial build it returns an empty result with a notice, not an error.

Input Schema

Name	Required	Description
`limit`	No	Results per page (1–100, default 20).
`query`	Yes	Free-text keywords matched against bill titles and summaries (e.g. "semiconductor export controls"). Tokens are AND-combined.
`offset`	No	Pagination offset.
`billType`	No	Restrict to a bill type (hr, s, hjres, sjres, hconres, sconres, hres, sres).
`congress`	No	Restrict to a single congress (e.g. 119). Omit to search the whole mirrored window.
`originChamber`	No	Restrict to the originating chamber.

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.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent/openWorld annotations: discloses that it queries a local mirror rather than the live API, that the mirror is a bounded congress window, what is and isn't indexed (title/summary yes; policy area and full bill text no), BM25 ranking, and a truncated summary preview. The empty-result-with-notice behavior is a genuinely useful non-obvious trait.

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

Conciseness5/5

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

Front-loads the core capability, then index scope, then return shape, then filters, then the mirror caveat — a logical ordering with no filler sentences despite its length.

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?

For a six-parameter search with an output schema, the description supplies everything an agent needs: what is searched, how results are ranked and shaped, how to narrow, and the failure mode on an unbuilt mirror.

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

Parameters3/5

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

Schema coverage is 100% and the schema already documents AND-combined tokens, enum values, and pagination bounds. The description only restates that congress, billType, and originChamber are narrowing filters, adding little syntax or semantics beyond structured fields, so baseline 3 applies.

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

Purpose5/5

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

States a specific verb and resource ('Keyword-search U.S. bills by title and CRS summary text') and immediately positions it against both the upstream API ('it has no keyword search') and the sibling lookup tool. An agent can distinguish it from congressgov_bill_lookup without inspecting either schema.

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

Usage Guidelines5/5

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

Explicitly frames this as the discovery path and names congressgov_bill_lookup as the follow-up step using the returned derived id. It also tells the agent when to narrow with congress/billType/originChamber and what happens on a cold mirror ('empty result with a notice, not an error').

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

All congressgov-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.