SiteCheck Company Records

US Congress bill status from the official GPO GovInfo

gov_govtrack_congress

Read-only

US Congress bill status from the official GPO GovInfo BILLSTATUS bulk XML (the GovTrack API it replaces has closed): title, sponsor, introduced date, latest action and official congress.gov link for one bill by congress, bill type and number. Covers congresses with BILLSTATUS files (119 at test time). Usually answers in a few seconds, up to 17 s on slower calls; allow a 30 s timeout. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "congress": "<congress>",
      "type": "<type>",
      "number": "<number>"
    },
    "name": "gov_govtrack_congress"
  }
}

Input Schema

Name	Required	Description
`type`	Yes	Bill type: hr, s, hres, sres, hjres, sjres, hconres or sconres
`number`	Yes	Bill number, digits, 1 to 5 digits
`congress`	Yes	Congress number, e.g. 119

Output Schema

Name	Required	Description	Default
`type`	No
`title`	No
`number`	No
`source`	No
`sponsor`	No
`congress`	No
`checkedAt`	No
`updatedAt`	No
`congressUrl`	No
`latestAction`	No
`sponsorParty`	No
`sponsorState`	No
`introducedDate`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare readOnly/openWorld; the description adds substantial operational context beyond them: typical latency of a few seconds up to 17 s, an explicit 30 s timeout recommendation, a $0.002 USDC per-successful-call price via x402 on Base/Solana/Arc, and the guarantee that failed calls are not charged. These are exactly the cost, latency and billing traits an agent needs before invoking a paid tool.

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?

Front-loaded with purpose and output fields, then latency/timeout and pricing in short trailing sentences; every sentence carries information. The first sentence is long and packs source, replaced-API note and return fields together, which slightly hurts scannability.

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?

With an output schema present, the description need not describe return values, and it instead covers the things the structured fields cannot: latency budget, timeout, payment mechanics, no-charge-on-failure, and congress coverage. Nothing an agent needs to call this correctly and budget for it 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 coverage is 100%, so baseline is 3; the schema already documents all three parameters including the bill-type values and the congress example. The description adds only marginal meaning, mainly the implied constraint that congress must have a BILLSTATUS file, without specifying format or validation details 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?

States a specific verb+resource: retrieve US Congress bill status (title, sponsor, introduced date, latest action, congress.gov link) for one bill by congress, type and number. It also names its provenance (GPO GovInfo BILLSTATUS bulk XML) and distinguishes itself from the closed GovTrack API, so an agent can tell it apart from sibling gov_* 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?

Gives clear context: single-bill lookup keyed by congress/type/number, and notes coverage limits ('congresses with BILLSTATUS files, 119 at test time'), which tells the agent when the call will fail. It does not name an alternative for bulk or multi-bill queries or for older congresses, so it stops short of explicit when-not routing.

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

All SiteCheck Company Records 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.

Resources

Need Help?