nyc-311-mcp

ll47_service_request_report

Generates monthly and fiscal-year-to-date NYC 311 service request reports by complaint type, agency, status, and average/median days to close for citywide, borough, or district views.

Instructions

Rebuilds the monthly 311 service request report of former Charter § 1075(b) (Local Law 47 of 2005; repealed by Local Law 69 of 2023): for a month and the fiscal year to date, totals by category (the City's complaint type) and by agency, totals by status, and the average (and median) days to close for each category and agency. Citywide, one borough, one community district or one council district; or by_district for a table of every district. From BoardStat's nightly files. Citywide and borough answers give totals by problem only, unless read_every_district is true. A BetaNYC rebuild from NYC Open Data, not the City's official report. No ZIP codes, nothing before 2020.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ll47_service_request_report"
  }
}

Input Schema

Name	Required	Description
`limit`	No	How many categories and category-agency rows (with by_district: districts) to list (default 50).
`month`	No	Month, YYYY-MM; the answer also covers the fiscal year to date through it. Default: the newest complete month. Not with fiscal_year.
`borough`	No	One borough. Give at most one of borough, community_district, council_district; none = citywide. With by_district, narrows the table.
`by_district`	No	A table with one row per district or borough of this kind: requests in the month and fiscal year, and the top problem.
`fiscal_year`	No	NYC fiscal year: 2027 or 'FY2027' = 2026-07-01 to 2027-06-30, cut to the data if not over. Not with month.
`council_district`	No	Council district, 1 to 51. Not with community_district.
`community_district`	No	306, BK06 or 'Brooklyn 6' (all forms: server instructions). Not with council_district.
`read_every_district`	No	Citywide or borough only: read every community district file to add agencies, statuses and days to close. A large download (about 860 MB citywide in November 2026), cached until the next build.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.2.0Nov 12, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: it discloses the data provenance (BetaNYC rebuild from NYC Open Data, not the official report), coverage limits (no ZIP codes, nothing before 2020), the caveat that citywide/borough answers give totals by problem only unless read_every_district is true, and that this flag triggers an ~860 MB cached download. It does not discuss permissions, caching staleness beyond nightly builds, or output shape in any detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded in the first sentence, which is good, but the remainder is a dense run-on of parentheticals and legal citations ("former Charter § 1075(b) (Local Law 47 of 2005; repealed by Local Law 69 of 2023)") that consume attention without helping tool selection. It is information-rich but poorly structured for scanning.

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 zero-required-parameter reporting tool with a fully documented schema and no output schema, the description covers provenance, coverage limits, the costly-flag tradeoff, and the geographic scope options. The main gap is that it never describes the response shape or how limit interacts with the returned rows.

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 100%, so the schema already documents all eight parameters, including mutual-exclusion notes and the community district format variants. The description adds little parameter-level meaning beyond restating that by_district yields a district table and that read_every_district is a large download; baseline 3 applies.

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?

The description names a specific verb and artifact ("Rebuilds the monthly 311 service request report") and enumerates exactly what the output contains: totals by complaint type and agency, totals by status, and average/median days to close. It also bounds the geography options and states the data source, so an agent can distinguish it from generic query siblings.

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?

It gives clear selection conditions: month versus fiscal year (mutually exclusive), citywide/borough/community district/council district, and by_district for a per-district table. Exclusions are stated inline ("Not with fiscal_year", "Not with community_district"), but it never names a sibling tool as an alternative for adjacent needs.

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