nyc-council-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LEGISTAR_TOKEN | No | Free Legistar API key. Required for live API tools such as get_bill, get_upcoming_hearings, and get_votes. Register at council.nyc.gov/legislation/api. | |
| LEGISTAR_DB_PATH | No | Path to your built legistar.db SQLite index. Required for local fast-path tools such as search_bills, vote_breakdown, and get_bill_history. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_billA | Get a specific bill by its intro/file number from the live Legistar API. Legistar file numbers are type-prefixed (e.g. 'Int 0349-2024', 'Res 0232-2024'). A type-prefixed number returns that one matter. A bare 'NNNN-YYYY' number is AMBIGUOUS — the same number can be both an Introduction and a Resolution; if it matches more than one matter the call is REJECTED with an error naming every match, and you re-call with the exact type-prefixed file number. A single match returns the authoritative record. |
| get_bill_historyA | Get the full legislative history of a bill — hearings, referrals, votes, and status changes. Live API data, authoritative. |
| get_upcoming_hearingsA | List upcoming NYC Council committee hearings and Stated meetings. Real-time data — use this for scheduling, not the local index. Each event's EventItems array is populated with its agenda items (the bills/matters on the agenda) via a follow-up call per event; pass include_agenda=false to skip that and return events faster with EventItems empty. |
| get_council_memberA | Look up an NYC Council member by name. Returns current contact info and active status. PersonWWW2 may carry a PersonWWW2_warning (and the original value in PersonWWW2_upstream) when the upstream link is known or suspected wrong. |
| get_committeeB | Look up an NYC Council committee by name. Returns current membership count and details. |
| get_votesA | 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. |
| list_recent_legislationA | List the most recently introduced NYC Council legislation. Use this to catch bills introduced since the last index update. |
| search_legislation_liveA | Search NYC Council legislation via the live Legistar API. Slower than search_bills but always current — use when the local index may be stale. Multi-word queries match matters whose title contains ALL the words (in any order), so 'section 254 capital' works — you do NOT need a single generic token. Wrap a phrase in double quotes to require those words to be adjacent. Note: Legistar's OData API has no full-text relevance ranking, so results are ordered by introduction date, not by how well they match. To find OLDER legislation, set order='date_asc' (oldest first) rather than raising the limit. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
The tools mostly target distinct resources (bill, history, hearings, member, committee, votes, recent legislation, search), but get_bill_history and get_votes both cover vote/roll-call information and their boundary is muddied by references to absent tools like vote_breakdown and 'local get_bill_history.' Inputs sometimes distinguish them (file number vs EventItemId), but the repeated local/live framing confuses a set that contains only live tools.
All names use predictable snake_case with a leading verb: get_, list_, search_. Minor compound forms like get_bill_history and search_legislation_live are still readable and consistent with the pattern.
Eight tools is well within the appropriate range for a read-only legislative lookup server. Each tool maps to a distinct resource or action, so the count itself is well-scoped.
The descriptions repeatedly direct agents to search_bills, vote_breakdown, and a local index that are not in this server, creating significant dead ends. In particular, get_votes requires an EventItemId, but the only in-set source is upcoming hearing agenda items; the description explicitly says live get_bill_history returns an event ID rather than an event item ID, leaving no reliable path to past roll-call votes.