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

nyc-311-mcp

by BetaNYC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

boardstat_link

Generate a prefiltered BoardStat district URL with dates, problems, descriptions, agency, and status set, so users can open the page and verify 311 service request numbers.

Instructions

A link to BoardStat's district page with the given district, dates, problems, descriptions, agency and status already set, so a person can see and check the numbers. Problem and description names are checked against BoardStat's data.

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

Input Schema

NameRequiredDescriptionDefault
agencyNoAgency code as 311 writes it, e.g. 'NYPD'.
statusNo'not_closed' = any status but Closed.
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

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses that problem and description names are validated against BoardStat's data, hinting at possible rejection of invalid names, and that the output is a link for human viewing. It does not say what happens on validation failure, whether the link is stable/expiring, or what the result looks like when no district is supplied despite zero required parameters.

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?

A single tight sentence that front-loads what the tool produces and follows with the purpose and the validation caveat. No filler or repetition, though the trailing 'so a person can see and check the numbers' is slightly informal for a technical definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter, zero-required link-builder with no output schema and no annotations, the description covers the essentials of what is produced and why. It leaves open how the tool behaves with no district specified and how date parameters default, which matters given that every parameter is optional.

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 11 parameters including the council_district/community_district exclusion and the fiscal_year format. The description adds only the validation semantics for problem/description names; it omits last_days, fiscal_year, and exclude_descriptions entirely, so it does not meaningfully exceed the schema baseline.

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?

The description uses a concrete verb-plus-resource framing: it produces a link to BoardStat's district page with named filters pre-applied. That is clearly distinct from data-returning siblings like district_summary or boardstat_status. It stops short of explicitly naming a sibling it replaces or complements, so it lands at 4 rather than 5.

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?

The clause 'so a person can see and check the numbers' implies the intended context: producing a human-shareable, verifiable view rather than machine-readable data. However, there is no explicit when-to-use versus when-to-use-a-sibling statement and no exclusion guidance, leaving the agent to infer that this is the shareable-URL counterpart to the data 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