What can you do with this server?

This server provides access to NYC's 311 public API, allowing you to check city services, emergency alerts, and track service requests. * Check city services calendar (get_calendar): Look up Alternate Side Parking, trash/recycling/compost collections, and public school status for a single date or a date range (up to 90 days). Defaults to today in New York time if no date is provided. * Check emergency & weather status (get_status): Get the current status for one of five condition types: * CodeBlue — extreme cold weather shelter alerts * FireHydrant — fire hydrant clearing status * OEM — Office of Emergency Management active alerts * SnowOnSidewalk — snow-on-sidewalk clearing status * SnowOnStreet — snow-on-street clearing status * Look up a single 311 service request (get_service_request): Retrieve details (agency, problem type, status, timestamp, and address) for one service request by its number (format 311-XXXXXXXX). * Bulk look up multiple 311 service requests (get_service_request_list): Retrieve details for several service requests in a single call by providing an array of service request numbers.

How do I use nyc-311-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nyc-311-mcp Check alternate side parking for today." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

nyc-311-mcp

by BetaNYC

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

nyc-311-mcp

An MCP (Model Context Protocol) server for the NYC 311 Public API — the city-services calendar, emergency and weather status alerts, and 311 service-request lookup.

NYC 311 is the city's central hub for non-emergency city services. This server exposes the public 311 API so an AI assistant can answer questions like whether alternate-side parking is suspended today, whether a Code Blue cold-weather alert is in effect, or what the status of a filed service request is.

Vibe coded with Claude by BetaNYC.

What it does

Exposes 4 tools over MCP:

Tool	Description
`get_calendar`	Alternate Side Parking, Collections (trash/recycling/compost), and Schools status for a date or range (max 90 days)
`get_status`	Current city status for an emergency or weather condition (Code Blue, fire hydrants, OEM alerts, snow)
`get_service_request`	Look up one 311 service request by number
`get_service_request_list`	Bulk look up multiple service requests in one call

Related MCP server: Weather MCP Server

Tools reference

`get_calendar`

Returns Alternate Side Parking, Collections (trash/recycling/compost), and Schools status for a single date or a date range. The range may not exceed 90 days. If no parameters are given, it defaults to today. Dates are interpreted in the America/New_York timezone — "today" means today in New York, regardless of the server's local time.

Parameter	Type	Required	Default	Description
`date`	string	no	today	Single date, YYYY-MM-DD — used for both ends if no range given
`from_date`	string	no	—	Range start, YYYY-MM-DD
`to_date`	string	no	—	Range end, YYYY-MM-DD

get_calendar()                                       → today
get_calendar(date="2026-07-04")
get_calendar(from_date="2026-07-01", to_date="2026-07-07")

Sample response (a normal weekday):

{
  "days": [
    {
      "today_id": "20260622",
      "items": [
        { "type": "Alternate Side Parking", "status": "IN EFFECT", "details": "Alternate side parking and meters are in effect." },
        { "type": "Collections", "status": "ON SCHEDULE", "details": "Trash, recycling, and compost collections are on schedule." },
        { "type": "Schools", "status": "OPEN", "details": "Public schools are open." }
      ]
    }
  ]
}

The three type values are Alternate Side Parking, Collections (trash, recycling, and compost), and Schools. On holidays each item also carries an exceptionName — for example, a Memorial Day lookup returns "status": "SUSPENDED" with "exceptionName": "Memorial Day 2026".

`get_status`

Returns the current city status for one emergency or weather condition.

Parameter	Type	Required	Default	Description
`type`	string	yes	—	One of: `CodeBlue`, `FireHydrant`, `OEM`, `SnowOnSidewalk`, `SnowOnStreet`

`type` value	What it reports
`CodeBlue`	Extreme-cold-weather shelter alert (Code Blue)
`FireHydrant`	Fire-hydrant clearing status
`OEM`	Office of Emergency Management active alerts
`SnowOnSidewalk`	Snow-on-sidewalk clearing status
`SnowOnStreet`	Snow-on-street clearing status

get_status(type="CodeBlue")
get_status(type="SnowOnStreet")

`get_service_request`

Look up one 311 service request by its number. Returns the agency, problem type, status (Open / In Progress / Closed / Cancelled), timestamp, and address as provided by the API.

Parameter	Type	Required	Default	Description
`sr_number`	string	yes	—	Service request number, format `311-XXXXXXXX`

get_service_request(sr_number="311-17323508")

`get_service_request_list`

Bulk look up multiple service requests in a single call. Returns the same per-request data as get_service_request.

Parameter	Type	Required	Default	Description
`sr_numbers`	string[]	yes	—	Array of service request numbers

get_service_request_list(sr_numbers=["311-17323508", "311-17323514"])

Common workflows

Check today's city services before heading out

get_calendar()                       → is alternate-side parking suspended? are schools open?
get_status(type="SnowOnStreet")      → is street snow-clearing under way?

Watch for a cold-weather emergency

get_status(type="CodeBlue")          → is an extreme-cold shelter alert in effect?
get_status(type="OEM")               → any other active OEM alerts?

Plan around a holiday week

get_calendar(from_date="2026-07-01", to_date="2026-07-07")   → ASP / collection / schools across the week

Track filed complaints

get_service_request(sr_number="311-17323508")                          → one request's current status
get_service_request_list(sr_numbers=["311-17323508", "311-17323514"])  → several at once

Prerequisites

Node.js 18 or later
An NYC 311 Public API subscription key (free)

API key

Yes — a free API key is required. The NYC 311 Public API requires a subscription key on every request. Get one (free) from the NYC API portal and set it as the NYC_311_API_KEY environment variable:

Go to api-portal.nyc.gov and register / sign in.
Subscribe to the NYC 311 Public Developers product (see the table below for which product to choose).
On your profile page, copy a subscription key. Each subscription has a primary and a secondary key — either one works; the pair exists so you can rotate keys without downtime.
Set it as the NYC_311_API_KEY environment variable, e.g. export NYC_311_API_KEY="your-subscription-key".

The portal lists three NYC 311 products. This server's tools (calendar, status, and service-request lookup) only need the public read API:

Product	Use it if…	Approval
NYC 311 Public Developers	✅ Recommended for this server. General-public access to the read API, with a standard rate limit.	Self-serve
NYC 311 Public — High Demand	You need a higher rate limit than the standard tier provides.	Admin approval in some cases
NYC 311 Developer Partner	You need to create service requests (this server does not — it only reads).	Admin approval required

The key is sent as the Ocp-Apim-Subscription-Key header on every request. The server reads it lazily — it only fails when you actually call a tool without a key set, never at startup.

Installation

Option 1 — npx (no install required)

NYC_311_API_KEY=your_key npx @betanyc/nyc-311-mcp

Option 2 — global install

npm install -g @betanyc/nyc-311-mcp
NYC_311_API_KEY=your_key nyc-311-mcp

Option 3 — build from source

git clone https://github.com/BetaNYC/nyc-311-mcp.git
cd nyc-311-mcp
npm install
npm run build
NYC_311_API_KEY=your_key npm start

Run the test suite (builds first; no API key or network needed):

npm test

Configuration

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "nyc-311": {
      "command": "npx",
      "args": ["-y", "@betanyc/nyc-311-mcp"],
      "env": {
        "NYC_311_API_KEY": "your_key_here"
      }
    }
  }
}

Claude Code

Add to your project's .claude/settings.json:

{
  "mcpServers": {
    "nyc-311": {
      "command": "npx",
      "args": ["-y", "@betanyc/nyc-311-mcp"],
      "env": {
        "NYC_311_API_KEY": "your_key_here"
      }
    }
  }
}

Example usage

Once connected, you can ask your AI assistant things like:

"Is alternate-side parking suspended today?"
"Are schools open on July 4th?"
"Is there a Code Blue in effect right now?"
"What's the status of service request 311-17323508?"
"Look up these three 311 complaints for me."

Notes & limitations

Service-request lookup is by number only. The API resolves a known SR number (311-XXXXXXXX); it does not search complaints by address, agency, or area. For citywide complaint analysis, use the 311 Service Requests dataset on NYC Open Data instead.
Calendar range cap. get_calendar accepts a span of up to 90 days; longer ranges are rejected before the request is sent.
Response shapes. get_calendar returns the documented days / items structure. The status and service-request endpoints are returned as the API's raw JSON — their exact field set is defined by the upstream API and is passed through unchanged.
Rate limits are governed by your subscription tier on the NYC API portal, not by this server.

Data source

All data comes from the NYC 311 Public API, operated by the NYC Office of Technology and Innovation (OTI). Access requires a free subscription key.

This is an independent, community-built project from BetaNYC. It is not affiliated with, endorsed by, or an official product of the City of New York.

Part of BetaNYC's family of MCP servers for NYC and NYS civic data:

nyc-record-mcp — City Record notices: procurement, awards, public hearings
nyc-checkbook-mcp — City spending, contracts, budget, payroll, and revenue
nyc-council-mcp — City Council legislation, hearings, votes, and members
nyc-charter-laws-rules — NYC Charter, Administrative Code, and Rules of the City of New York
nys-openlegislation-mcp — New York State bills, laws, members, and committees

About BetaNYC

This project is built and maintained by BetaNYC, New York's civic technology and open-data community. We work to improve lives in New York through civic design, technology, data, and public-interest technology.

Come do civic tech with us. We run public events, meetups, and hands-on data classes throughout the year — including NYC School of Data and CityCamp NYC, and we host frequent civic-tech gatherings. See what's coming up on our events calendar.

Sustain this work. These MCP servers are free and open source. To help keep this work going and find BetaNYC's tools, please consider donating and becoming a Beta Builder.

Building on this? Tell us!

If you build something with this project, we'd love to hear about it. We can help other New Yorkers find it. BetaNYC publishes a weekly newsletter, This Week in NYC's Civic Technology and Open Data.

Subscribe to the newsletter to keep up with NYC civic tech, open data, and public-interest technology.
Built something, or found a story worth sharing? Submit a link for the newsletter and we'll consider it for an upcoming issue.

BetaNYC maintains a suite of open-source MCP servers for NYC and NYS civic data. See the full directory, with install details for each, at beta.nyc/ai-tools.

Working with the wider NYC Open Data portal? For citywide complaint analysis beyond single service-request lookup, the 311 Service Requests dataset lives on NYC Open Data. Query it, and the rest of the catalog, with socrata-mcp-server (socrata-mcp-server on npm), a third-party MCP by Nathan Storey.

Contributing

Issues and pull requests welcome at github.com/BetaNYC/nyc-311-mcp.

Releases

Releases are automated. Pushing a tag vX.Y.Z that matches the version in package.json triggers .github/workflows/release.yml, which runs the tests, publishes @betanyc/nyc-311-mcp to npm (with provenance), and creates a GitHub Release with generated notes. Version history lives in CHANGELOG.md. Publishing requires the NPM_TOKEN repository secret.

Support our work

Freedom isn't free. Support BetaNYC.

License

MIT License

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Available Tools

4 tools

get_calendarA

Get Alternate Side Parking, Garbage & Recycling, and Schools status for a date or date range (max 90 days). Dates are interpreted in America/New_York (Eastern Time); if no date is given, defaults to today in New York.

ParametersJSON Schema

Name	Required	Description
`date`	No	Single date, YYYY-MM-DD. Used for both from and to if no range is given.
`to_date`	No	Range end, YYYY-MM-DD
`from_date`	No	Range start, YYYY-MM-DD

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses timezone interpretation and default behavior, and the 90-day limit, but lacks details on error handling, authentication, or rate limits.

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?

Two sentences, no fluff, front-loaded with the most critical information (what tool gets, parameters, and important constraints). Every sentence earns its place.

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?

Covers main functionality, timezone, default, and range limit. Missing output format description and error conditions, but acceptable for a simple calendar tool with no output schema and three well-documented parameters.

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 description coverage is 100%, so baseline is 3. The description adds meaning beyond the schema: explains that 'date' can serve as both from and to, and clarifies the range max of 90 days, which is not in the schema.

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?

Description clearly states the verb 'Get' and resource 'Alternate Side Parking, Garbage & Recycling, and Schools status' for a date or date range, distinguishing it from sibling tools (get_service_request, get_service_request_list, get_status) which deal with service requests and status.

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?

Provides context on date range max (90 days) and timezone (America/New_York), but does not explicitly state when to use this tool versus siblings or any exclusions. No when-not or alternative tool guidance is given.

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

get_service_requestA

Look up one 311 service request by its number (format 311-XXXXXXXX). Returns agency, problem type, status, timestamp, and address.

ParametersJSON Schema

Name	Required	Description	Default
`sr_number`	Yes	Service request number, e.g. '311-17323508'

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are present, so the description bears full responsibility. It discloses the return fields (agency, problem type, status, timestamp, address), indicating it is a read operation. It does not mention error cases or limitations, but for a simple lookup, this is sufficiently transparent.

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?

The description is a single sentence of 17 words that immediately states the action and resource, followed by the input format and output fields. Every word contributes useful information; no fluff.

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?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is largely complete. It covers what, how, and what to expect. It could mention authentication or pagination but those are unnecessary for a single-lookup tool.

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 parameter is already documented. The description adds value by specifying the exact format ('311-XXXXXXXX'), which is more helpful than just the schema description. This exceeds the baseline of 3.

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 clearly specifies the action ('look up one 311 service request') and the resource ('by its number'). It distinguishes from sibling tool 'get_service_request_list' which lists multiple requests. The purpose is unambiguous.

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?

The description states the input format and what the tool returns. It implicitly differentiates from siblings (single vs list), but does not explicitly state when not to use or provide alternatives. Some guidance is provided through context.

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

get_service_request_listB

Bulk look up multiple 311 service requests by their numbers in a single call.

ParametersJSON Schema

Name	Required	Description	Default
`sr_numbers`	Yes	Array of service request numbers, e.g. ['311-17323508', '311-17323514']

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states it is a bulk lookup, but does not disclose rate limits, authentication requirements, behavior on invalid numbers, or that it is a read operation (implicit but not explicit).

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?

One clear sentence with no wasted words. It is appropriately front-loaded with the core action. Not a 5 because it could be slightly more informative without sacrificing conciseness.

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 a simple bulk lookup with one parameter, the description is adequate but lacks information about return values or error handling, especially given no output schema. Completeness is just satisfactory.

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 coverage is 100% with a clear description of the array of strings. The tool description adds no additional meaning beyond the schema; baseline 3 is appropriate.

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 clearly states the action (bulk look up) and resource (311 service requests) with a specific method (by their numbers in a single call). It distinguishes from sibling tools like get_service_request (single lookup) and get_calendar/get_status (unrelated).

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 description implies usage for bulk lookup but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_service_request for single lookups). No exclusions or context provided.

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

get_statusA

Get the current city status for an emergency or weather condition: Code Blue (cold weather), Fire Hydrant, OEM emergency notifications, Snow on Sidewalk, or Snow on Street.

ParametersJSON Schema

Name	Required	Description	Default
`type`	Yes	Status type to look up

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It clearly indicates a read operation ('Get the current city status') and lists the types, but does not disclose return format or caching behavior. However, it is consistent and straightforward.

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?

The description is a single sentence that is front-loaded with the action, followed by a concise list of types. No wasted words.

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?

Given the tool's simplicity (one parameter, no output schema), the description is fairly complete. It explains the action and the available types, though it could mention that the returned data is the current status of that type.

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% with one parameter having enum and description. The description adds semantic value by explaining each enum value in parentheses (e.g., 'Code Blue (cold weather)'), enriching beyond the schema's bare enum list.

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 clearly states the tool's purpose: 'Get the current city status' and lists five specific types, making it distinct from sibling tools like get_calendar and get_service_request.

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 description does not explicitly guide when to use this tool vs alternatives. It lists the status types but lacks context like 'use this for weather conditions, use get_service_request for specific requests.'

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.1Jul 7, 2026
- First observedget_calendar
- First observedget_service_request
- First observedget_service_request_list
- First observedget_status

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-07-07 02:00 across 4 tools

Disambiguation5/5

Each tool targets a distinct function: calendar info, single request lookup, batch request lookup, and emergency/weather status. No overlap in purpose.

Naming Consistency5/5

All tool names follow the consistent pattern 'get_<noun>' with snake_case, making them predictable and easy to understand.

Tool Count4/5

Four tools is a reasonable size for a focused read-only service, though it could be expanded with additional lookup or search tools without becoming unwieldy.

Completeness3/5

The server covers basic lookups and calendar/status, but lacks search by location, category, or the ability to create requests, leaving notable gaps for a 311 service.

Maintenance

ActivitySlowing

ResponsivenessResponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
nyc-property-intel
io.github.ccedacero
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
Real Estate Government Data
27

Related MCP Servers

Customized MCP Server
Weather Services Search
MorvanZhou
A
license
Not graded
quality
D
maintenance
A server that integrates the MCP library with OpenAI's API, allowing users to interact with various tools, such as the weather tool, through natural language queries.
Updated a year ago (2025-04-05 08:59 UTC)
MIT
Weather MCP Server
Weather Services Search
agentventure
F
license
B
quality
D
maintenance
An MCP server that provides weather information and alerts for US locations using the National Weather Service API, enabling retrieval of weather forecasts and active weather alerts.
Updated a year ago (2025-06-19 00:48 UTC)
2
-
Weather MCP Server
Weather Services Location Services Open Data
azwawy
F
license
Not graded
quality
D
maintenance
A demo MCP server that provides AI assistants access to live US weather data via the free National Weather Service API, offering forecast and alert tools without requiring an API key.
Updated 3 months ago (2026-06-12 22:24 UTC)
-
AI Assistant MCP Server
AI & Machine Learning Weather Services Autonomous Agents
baominh5xx2
F
license
Not graded
quality
C
maintenance
MCP server providing tools to chat with an AI agent, fetch weather data, and monitor agent status via the Model Context Protocol.
Updated 10 months ago (2025-11-09 13:45 UTC)
-

nyc-311-mcp

What it does

Tools reference

get_calendar

get_status

get_service_request

get_service_request_list

Common workflows

Check today's city services before heading out

Watch for a cold-weather emergency

Plan around a holiday week

Track filed complaints

Prerequisites

API key

Which product to subscribe to

Installation

Option 1 — npx (no install required)

Option 2 — global install

Option 3 — build from source

Configuration

Claude Desktop

Claude Code

Example usage

Notes & limitations

Data source

Related projects

About BetaNYC

Building on this? Tell us!

Related BetaNYC MCP servers

Contributing

Releases

Support our work

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`get_calendar`

`get_status`

`get_service_request`

`get_service_request_list`