nyc-311-mcp

Where this server's data comes from

about_data

Read-only

Explains where NYC 311 data comes from, how current and reliable it is, and how to verify, cite, or report errors, optionally narrowed to one dataset or tool.

Instructions

Where this server's data comes from and how far to trust it. For each kind of data: who publishes it and a link, whether it is an official record or BetaNYC's curation, how it was gathered, what BetaNYC changed (for example cleaned, address-matched, merged or counted), how current it is on this server, what it covers and what is missing, the terms of use and the credit line to print, where to check a figure at the official source, where to report an error (to the publisher, or in this server), which tools use it, and corrections that touched it. Call it whenever someone asks where an answer comes from, how current or accurate it is, or how to check or cite it. topic narrows it to one kind of data, or to the data behind one tool (give the tool's name). For who built this server, use about_betanyc. Topics on this server: calendar-and-status, service-request-lookup, 311-articles, built-in-911-lines, service-requests-by-district, ll47-service-request-reports, community-district-boundaries, council-district-boundaries, call-center-inquiries, service-level-agreements.

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

Input Schema

Name	Required	Description	Default
`topic`	No	One kind of data (a source id), or a tool name for the data behind that tool. Any case. Default: all.

Output Schema

Name	Required	Description
`note`	Yes
`topic`	Yes
`server`	Yes
`topics`	Yes
`catalog`	Yes
`sources`	Yes
`left_out`	Yes	Sources in the file that this server cannot show, and why
`source_file`	Yes	DATA-SOURCES.json on GitHub
`who_built_this`	Yes	Call about_betanyc for who built this server

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.3.0Nov 14, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds substantial context beyond that: it enumerates what each record contains (publisher, link, official vs. curated, transformations applied, currency, coverage gaps, terms of use, credit line, error-reporting path, corrections). It does not discuss response size or pagination, but with an output schema present that is a minor omission.

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 purpose and the usage trigger are front-loaded, which is good, but the middle is one very long comma-chained sentence enumerating a dozen record fields that is hard to parse at a glance. The information is relevant, yet it could be restructured into shorter sentences or a compact list without losing content.

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

Completeness5/5

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

For a single-optional-parameter, read-only metadata tool with an output schema, the description covers purpose, trigger conditions, the alternative tool, and the full set of valid topic values. Nothing an agent needs in order to call it correctly is missing.

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

Parameters5/5

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

Schema coverage is 100% and the schema already says topic accepts a source id or tool name, any case, default all. The description goes further by listing the actual valid topic values (calendar-and-status, service-request-lookup, 311-articles, etc.), which the schema does not enumerate — genuinely useful meaning added beyond the structured field.

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 opens with a specific statement of what the tool returns — provenance and trustworthiness of each data source — and explicitly separates itself from the sibling about_betanyc ('For who built this server, use about_betanyc'). An agent can distinguish it from every other sibling without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

It gives an explicit trigger ('Call it whenever someone asks where an answer comes from, how current or accurate it is, or how to check or cite it') and names the alternative tool for the adjacent question about the server's authors. Both when-to-use and when-to-use-something-else are stated.

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