Skip to main content
Glama

bill-commons

by org.billcommons
OverviewAdmin

build_legislative_evidence_packet

Compile a citation-ready evidence packet for a bill: full official record, legislative history timeline, votes with member-level detail, and hearings -- each explicitly labeled official vs. derived with source URLs.

Returns a `how_to_cite` block with a one-line `cite_as` sentence, a human
`permalink`, a JSON `download_url`, and a `snapshot_id` that changes if and
only if a cited fact about the bill changes -- so a reader can check later
whether the citation still holds. Snapshots are NOT archived; the id is a
change detector, not a way to retrieve an older packet.

Pass `question` to record what the packet was assembled to answer; it is
echoed into the artifact so a filed packet carries its own scope.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bill_idYes
questionNo
include_full_textNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / properties / question
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Question"
+}
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: snapshot_id changes only when cited facts change, snapshots are NOT archived, and `question` is echoed into the artifact. It does not mention permissions or explicitly state read-only behavior, but the 'compile' framing implies non-mutating.

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 multi-sentence but every sentence earns its place: purpose, return structure, snapshot semantics, and parameter note. It is front-loaded with the core action and avoids filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains return values well, including the citation block and download artifacts. It misses include_full_text semantics and potential error conditions, but for a complex assembly tool it is largely complete.

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 0%, so the description must compensate for parameter meaning. It explains `question` well, but `include_full_text` is not described at all, and `bill_id` only relies on its name. This is partial compensation; include_full_text's effect on the packet remains ambiguous.

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: 'Compile a citation-ready evidence packet for a bill.' It enumerates the packet's contents (official record, legislative history, votes, hearings) and explicitly distinguishes labed sources as official vs. derived, setting it apart from sibling tools like get_bill_record or trace_legislative_history.

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 clearly conveys when this tool is appropriate: when a comprehensive, citation-ready packet is needed rather than a single bill detail or vote list. It does not explicitly name alternatives or state when not to use it, but the scope is evident enough to guide selection.

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

All bill-commons toolsInspect
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.

Resources