Skip to main content
Glama
Sign In
nyc-council-mcp

nyc-council-mcp

by BetaNYC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_bill

Fetch a specific NYC Council bill by introductory or file number from the live Legistar API. Use type-prefixed numbers to avoid ambiguous bare-number errors.

Instructions

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.

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": {
      "file_number": "<file_number>"
    },
    "name": "get_bill"
  }
}

Input Schema

NameRequiredDescriptionDefault
file_numberYesBill file number, e.g. 'Int 0349-2024' or '0349-2024'

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.7.1

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the disclosure burden and does well: it reveals the live-API call, the multi-match rejection behavior, that the error enumerates every match, and the required recovery step. It omits auth/rate-limit expectations and any note about what the returned record contains, which keeps it short of a 5.

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 key constraint (type prefix) is front-loaded in the first two sentences, and the error/recovery path follows logically. The final two sentences overlap somewhat — "a type-prefixed number returns that one matter" and "a single match returns the authoritative record" restate the same guarantee — so it is efficient rather than maximally tight.

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 retrieval tool with no output schema, the description covers the critical risk (ambiguous bare numbers) and the recovery loop completely. The only gap is that 'authoritative record' is left vague, so an agent cannot anticipate the returned shape without calling.

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

Parameters4/5

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

Schema coverage is 100%, so a 3 is the baseline, and the description earns above that by explaining the semantic consequence of the two accepted formats — prefixed numbers are unambiguous, bare numbers may collide across Introduction and Resolution types. That is meaning the schema's terse example does not convey.

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 a specific bill") plus the sourcing context ("from the live Legistar API"), and pins down what identifies the record (type-prefixed file number). An agent can distinguish this lookup from record-history or search siblings 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 Guidelines4/5

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

Gives concrete conditional guidance: a type-prefixed number returns one matter, a bare 'NNNN-YYYY' is ambiguous and may be rejected, in which case re-call with the prefixed form. It never explicitly says when to choose this over search_legislation_live or how to obtain the file number in the first place, so it falls short of full alternative routing.

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

Deploy Server

Other Tools