congressgov-mcp-server

Congress.gov Daily Record

congressgov_daily_record

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

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

TableJSON 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

A4.3/5.0

Behavior4/5

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

With readOnlyHint, openWorldHint, and idempotentHint already provided by annotations, the description adds genuine behavioral context: the hierarchical navigation flow, the fact that 'articles' returns format URLs, and that 'content' reads a bounded character window at a time. This goes beyond what annotations alone convey.

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

Conciseness5/5

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

The description is well-structured and compact: a front-loaded purpose, then the operation hierarchy, then concrete usage instructions. Every sentence contributes either scope or navigation guidance, with no filler or repetition.

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 4-operation, 9-parameter tool, the description covers the operation flow, the relationship between operations, and the bounded-window content model. The output schema and 100% parameter coverage supply the remaining return-value and parameter details, so nothing needed for correct invocation is missing.

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 description coverage is 100%, so the schema already carries the parameter detail. The description adds high-level operation semantics and the windowed-reading behavior, but it does not need to restate what the schema already documents. It earns the baseline rather than exceeding it.

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

Purpose5/5

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

The description opens with a direct verb-resource statement ('Browse the daily Congressional Record') and names concrete contents: floor speeches, debates, and legislative text. It then maps the four operations to a hierarchy, making the tool's role clear and distinguishing it from sibling bill/committee-focused tools.

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 gives explicit routing guidance among the tool's own operations: 'Use list to find recent volumes, issues to see what's in a volume, and articles to access individual speeches.' It does not explicitly contrast with sibling tools, but the daily-record scope is plainly distinct from the sibling bill and committee tools.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation4/5

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

Naming Consistency5/5

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

Tool Count5/5

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

Completeness4/5

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

Congress.gov Daily Record

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources