Skip to main content
Glama
amurshak

CongressMCP-full

by amurshak

Retrieve the full statutory text of a bill section (GovInfo)

get_bill_section

Retrieve the full statutory text of a single bill section -- or an addressable sub-section chunk -- parsed from the bill's GovInfo Bill DTD XML.

Instructions

Retrieve the full statutory text of a single bill section -- or an addressable sub-section
chunk -- parsed from the bill's GovInfo Bill DTD XML.

Call this after search_bill_text or get_bill_toc to read a specific section by its section_id
(e.g. "D:H/T:I/S:3501"). Fully-qualified section ids and chunk ids resolve directly; a bare
section number (e.g. "101") resolves only when it is unique across the bill. Every id
get_bill_toc returns resolves here, including structural containers such as a division,
title, or subtitle ("D:C/T:XXXI/ST:B"), which return their heading plus child descriptors
when the subtree exceeds max_bytes. The returned text
carries operative and quoted (amendatory) language in reading order; when the section is
subdivided, child chunk descriptors are included. Text is capped at max_bytes, measured as
UTF-8 encoded bytes of the returned text field, clamped to 1,000-100,000.

is_amendatory and amends describe the returned text. For a single unit they are the same
values a search_bill_text hit reports for that section_id; when the response assembles
several units (a subdivided section or a container that fit max_bytes), is_amendatory is
true if ANY included unit amends and amends is the union of their targets. When
is_amendatory is true, quoted language in text is matter the section INSERTS INTO or
STRIKES FROM existing law -- an instruction to change another statute, not a freestanding
requirement of this bill -- so present it as an amendment to the cited target, not as the
bill's own rule. Each amends entry is {kind: "usc"|"public_law", cite}. amends is citations
found, never a complete list: it resolves no named Acts, no chapter- or title-level
amendments, and no non-U.S. Code targets, so a non-empty list can still be short. A
heading-plus-children-descriptors response (subtree too large for max_bytes) reports the
addressed unit's own values; each child's text arrives labeled when fetched.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
numberYes
versionNo
congressYes
bill_typeYes
max_bytesNo
section_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description fully carries the burden of behavioral transparency. It discloses critical behaviors: the max_bytes cap with clamping range, handling of structural containers (heading plus child descriptors when subtree exceeds max_bytes), the semantics of is_amendatory and amends, including the union behavior for multiple units and the limitations of amends (e.g., not resolving named Acts). It also explains how to interpret quoted language as amendatory. This is exceptionally transparent.

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 long but dense, with every sentence contributing technical detail essential for correct usage. It is front-loaded with the primary purpose and then systematically covers id resolution, output behavior, and amendatory interpretation. The structure is logical, though the length is substantial. Slight deduction for not using shorter paragraphs or bullet-like separation, but it's not verbose.

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?

Given the tool's complexity (multiple id types, max_bytes semantics, amendatory flags, container handling), the description is remarkably complete. It explains the return behavior, field semantics, and edge cases (e.g., non-unique bare section numbers, incomplete amends lists). Since an output schema exists, the description doesn't need to outline the full return structure, but it covers all operational nuances. This is a comprehensive description for a complex tool.

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

Parameters4/5

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

The input schema has 0% description coverage, so the description must compensate. It provides detailed semantics for section_id (how IDs resolve, examples) and max_bytes (UTF-8 bytes, clamping range, effect on output). It indirectly covers congress, bill_type, and number by framing them as part of bill identification, and version is not discussed but likely self-explanatory. While not all parameters are explicitly detailed, the most complex ones are thoroughly explained, providing solid added value beyond the schema.

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 specific verb and resource: 'Retrieve the full statutory text of a single bill section -- or an addressable sub-section chunk.' It clearly differentiates from sibling tools by mentioning that it should be called after search_bill_text or get_bill_toc, and describes its role in the workflow. The purpose is unambiguous and distinct.

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 explicitly states when to call this tool: 'Call this after search_bill_text or get_bill_toc to read a specific section by its section_id.' It also explains ID resolution rules (fully-qualified, chunk IDs, bare section numbers) and describes behavior for containers. While it doesn't explicitly state when NOT to use it, the usage context is clear and directs the agent appropriately. Slight deduction for lacking explicit exclusions or alternative selection guidance.

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/amurshak/congressMCP'

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