nyc-council-mcp

get_bill_history

Retrieve a bill's complete legislative history, including hearings, referrals, votes, and status changes, using its Legistar matter ID.

Instructions

Get the full legislative history of a bill — hearings, referrals, votes, and status changes. Live API data, authoritative.

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": {
      "matter_id": "<matter_id>"
    },
    "name": "get_bill_history"
  }
}

Input Schema

Name	Required	Description	Default
`matter_id`	Yes	Legistar matter ID (returned by search_bills or get_bill)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.7.1Nov 9, 2026

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are supplied, so the description carries the full burden. 'Live API data, authoritative' usefully discloses data freshness and source reliability, and the verb 'Get' implies a read-only operation, but nothing is said about response size, pagination of long histories, or error behavior for an invalid matter_id.

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?

Two short sentences with zero filler, and the core capability is front-loaded before the data-quality note. Nothing redundant or padded.

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?

For a single-parameter read tool with no output schema and no annotations, the description covers what the tool returns (hearings, referrals, votes, status changes) and the data's provenance. A note on how the history is ordered or bounded would close the remaining gap.

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?

Only one parameter exists and schema coverage is 100%, with the schema itself explaining that matter_id is a Legistar matter ID returned by search_bills or get_bill. The description adds no additional meaning about the identifier beyond reinforcing that the subject is a bill.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get the full legislative history of a bill') and enumerates the content returned: hearings, referrals, votes, and status changes. It does not explicitly contrast with get_bill or get_votes, so an agent must infer that this is the aggregate-history view rather than a single-record lookup.

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 only implied by the phrase 'full legislative history' — an agent can reasonably conclude it should be called when the timeline matters. There is no explicit when-to-use versus get_bill/get_votes guidance and no stated prerequisites or exclusions.

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

Deploy Server