nyc-council-mcp

get_votes

Retrieve how each member voted on a specific NYC Council agenda item by its EventItemId, using live API data for current vote records.

Instructions

Get the vote record for a specific agenda item by its EventItemId. Shows how each member voted. Live API data — use for freshness. For a bill's roll call from the local corpus, prefer vote_breakdown (grouped roll calls with a positions-only tally) or the local get_bill_history, which returns each action's event_item_id directly. EventItemIds also come from an event's agenda items (GET /events/{EventId}/eventitems) — e.g. the EventItemId field inside each event returned by get_upcoming_hearings. Note: the live get_bill_history's MatterHistoryEventId is an EVENT id, not an event ITEM id, whereas each local history action's event_item_id IS the id this tool takes.

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": {
      "event_item_id": "<event_item_id>"
    },
    "name": "get_votes"
  }
}

Input Schema

Name	Required	Description	Default
`event_item_id`	Yes	EventItemId of the agenda item (from /events/{EventId}/eventitems, e.g. the EventItems array in get_upcoming_hearings results)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.7.1Nov 9, 2026

TDQS

A4.6/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 that the data is live API data, that it returns how each member voted, and clarifies ID semantics. It does not describe authentication, rate limits, pagination, or error behavior, so it is strong but not exhaustive.

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?

The purpose is front-loaded, followed by alternatives and caveats, and most sentences earn their place by preventing ID confusion. However, the description is dense and uses a long parenthetical plus a note that could be split into clearer steps.

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 one-parameter read tool with no annotations or output schema, the description explains the return content, data source, and where to find the required ID. It is sufficient for invocation, though it omits operational details such as response format or error behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema already documents event_item_id at 100% coverage, the description adds a critical semantic distinction between EVENT ids and event ITEM ids. It also tells the agent that local history action event_item_id is the correct value this tool accepts, which materially reduces misuse.

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 and resource: get the vote record for a specific agenda item by EventItemId, and explicitly says it shows how each member voted. It also distinguishes live API data from local-corpus alternatives, so an agent can identify the tool's role without opening the schema.

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?

Explicitly says to use this for live freshness and to prefer vote_breakdown or local get_bill_history for a bill's roll call from the local corpus. It also names where EventItemIds come from and warns that the live get_bill_history MatterHistoryEventId is an EVENT id, not an event ITEM id.

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

Deploy Server