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

nyc-311-mcp

by BetaNYC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

still_open

Retrieve unresolved NYC 311 service requests in a district, sorted oldest first with days open and agency counts, to identify reports still pending.

Instructions

Requests in a district that are not yet closed, oldest first, with days open, plus a count and the oldest date for each agency. With no dates, covers every request since 2020. Optional problem, description and agency filters. From BoardStat (BetaNYC, NYC Open Data, 2020 on); not an official City report. 311 counts are reports, not problems; 'closed' is not 'fixed'.

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": "still_open"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoRows to list (default 25).
agencyNoAgency code as 311 writes it, e.g. 'NYPD'.
to_dateNoEnd, YYYY-MM-DD, inclusive.
problemsNoBoardStat problem names, e.g. ['HEAT/HOT WATER']; any case.
from_dateNoStart, YYYY-MM-DD, inclusive.
last_daysNoThe last N days of data, ending on the newest request's day (not today).
fiscal_yearNoNYC fiscal year: 2027 or 'FY2027' = 2026-07-01 to 2027-06-30.
descriptionsNo311 descriptors, e.g. ['Blocked Bike Lane']; a missing one is '(none)'.
council_districtNoCouncil district, 1 to 51. Not with community_district.
community_districtNo306, BK06 or 'Brooklyn 6' (all forms: server instructions). Not with council_district.
exclude_descriptionsNoLeave out these descriptions instead of keeping only them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

A3.9/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 it does substantial work: sort order, derived fields (days open, per-agency counts, oldest date), the default 2020-onward window, data provenance and beta/non-official status, and the important semantic caveat that 'closed' is not 'fixed' and counts are reports not problems. It stops short of covering pagination/truncation behaviour tied to limit or any rate/auth considerations.

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?

Front-loaded with the core behaviour, then defaults, then caveats — every sentence carries information an agent needs, and the terse '311 counts are reports, not problems; closed is not fixed' phrasing is maximally dense without being cryptic.

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 an 11-parameter, no-annotation, no-output-schema tool, the description adequately explains both the filter model and the shape of the result (rows with days open, plus per-agency count and oldest date). The gap is result-set behaviour — how limit interacts with the aggregates and whether totals are computed pre- or post-limit.

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 the baseline is 3, but the description adds meaning the schema does not: omitting dates silently defaults to all requests since 2020, and it summarises the problem/description/agency filter families. It does not clarify precedence among overlapping time parameters (from_date/to_date vs last_days vs fiscal_year), which is the main remaining ambiguity.

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 concrete verb and resource plus scope: open (not-yet-closed) requests in a district, oldest first, with days-open and per-agency aggregates. That is far more specific than a generic 'list requests', though it never names the sibling it complements (e.g. find_requests, district_summary), so an agent must infer the boundary.

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 implied rather than stated: 'With no dates, covers every request since 2020' tells the agent what happens when filters are omitted, and the optional filters are listed. There is no explicit when-to-use-this-instead-of-X guidance against the many sibling listing/summary tools.

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