Skip to main content
Glama

LiveDataLink

by io.github.blackboxfoundry
OverviewDiscussionsAdmin

govinfo_legislation_search

Read-onlyIdempotent

Search LiveDataLink's self-hosted official GovInfo Bill Status snapshot across bill number/title, all published titles, sponsor, policy area, legislative subjects, and committee names, with optional enacted and multi-version filters. Returns stable bill identifiers, sponsor/status facts, pagination, source XML hashes, and provenance. Use this for 'find 118th Congress bills about aviation safety', 'which border bills became law?', or 'bills assigned to the Finance Committee with multiple text versions'. Coverage is complete for HR and S in the 118th Congress only; resolutions and other Congresses are excluded. For Congress.gov's live/current API view, use the existing Congress tools instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum bills. Default 20.
queryYesBill number/title phrase, sponsor name, policy area, subject, or committee phrase.
offsetNoBills to skip. Default 0.
bill_typeNoHosted measure type: HR for a House bill or S for a Senate bill. Resolutions are outside this v1 snapshot.
policy_areaNoOptional exact policy-area label, case-insensitive.
enacted_onlyNoWhen true, require at least one law citation in the captured Bill Status XML.
response_formatNoHuman-readable markdown or machine-readable JSON. Default markdown.
multiple_text_versions_onlyNoWhen true, require at least two published GovInfo text-version links.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • addedInput schema / properties / limit / maximum
      Added value: +100
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • changedInput schema / properties / limit / type
      Previous value: -"number"New value: +"integer"
    • addedInput schema / properties / offset / maximum
      Added value: +10000
    • addedInput schema / properties / offset / minimum
      Added value: +0
    • changedInput schema / properties / offset / type
      Previous value: -"number"New value: +"integer"
    • addedInput schema / properties / policy_area / maxLength
      Added value: +200
    • addedInput schema / properties / policy_area / minLength
      Added value: +1
    • addedInput schema / properties / query / maxLength
      Added value: +200
    • addedInput schema / properties / query / minLength
      Added value: +1
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld/idempotent, so safety is covered. The description adds real context beyond them: the dataset is a fixed snapshot (not live), coverage is limited to HR and S in the 118th Congress, and returns include source XML hashes and provenance. Auth/rate-limit behavior is not mentioned, keeping it from a 5.

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-loads what it searches, then returns, then examples, then scope limits, then the alternative. Dense but every sentence carries distinct information; the field enumeration in sentence one is slightly long but justified.

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 8 fully-documented params, no output schema, and a rich sibling set, the description covers search surface, return contents, coverage boundaries, and routing to alternatives. Nothing essential 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 coverage is 100% and the schema itself documents each parameter with defaults and enum meanings, so the baseline is 3. The description's field list (all published titles, committee names) and its mapping of 'enacted' and 'multi-version' filters to the boolean params adds only marginal meaning over 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 (search) and a precise resource (LiveDataLink's self-hosted GovInfo Bill Status snapshot), enumerating the searchable fields. It explicitly distinguishes itself from the sibling congress_* tools by contrasting the static snapshot against Congress.gov's live API view.

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?

Provides three concrete triggering examples ('118th Congress bills about aviation safety', 'border bills became law', 'bills assigned to Finance Committee with multiple versions') plus explicit exclusions (resolutions and other Congresses excluded) and a named alternative for the live view.

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

All LiveDataLink toolsInspect
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