Skip to main content
Glama

bill-commons

by org.billcommons
OverviewDiscussionsAdmin

build_legislative_evidence_packet

Read-onlyIdempotent

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.

  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
Behavior5/5

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

Goes well beyond the annotations (readOnly/idempotent/non-destructive) by disclosing that snapshots are NOT archived, that snapshot_id is a change detector rather than a retrieval handle, and that it only changes when a cited fact changes. It also describes the returned how_to_cite structure and labeling of official vs. derived content — exactly the non-obvious behavior an agent needs.

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?

Three tight paragraphs, front-loaded with what the packet contains, then the return shape, then the optional scoping parameter. Slightly long, but each sentence carries distinct information and nothing is redundant.

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 no output schema, the description itself documents the return surface (cite_as sentence, permalink, download_url, snapshot_id) and its semantics. Combined with the labeling behavior and the snapshot caveat, an agent has everything needed to call and interpret this tool.

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 0%, so the description must compensate. It explains `question` well (recorded scope, echoed into the artifact) but leaves `bill_id` and `include_full_text` undefined — an agent cannot tell from the description whether include_full_text defaults on or what format bill_id takes.

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 ('Compile') and resource ('citation-ready evidence packet for a bill') and enumerates exactly what the packet contains (official record, history timeline, member-level votes, hearings). This is clearly distinguishable from siblings like get_bill_record (raw record) and trace_legislative_history (history only), since it composes all of them into one cited artifact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: an agent can infer this is the tool for producing a citable, self-contained packet, and the snapshot/citation discussion hints at the 'check a citation later' workflow. However, it never explicitly contrasts with get_bill_record or trace_legislative_history, nor states when NOT to build a packet.

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
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