nyc-restroom-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | error, warn, or info (default info). Logs go to stderr only. | info |
| SOCRATA_APP_TOKEN | No | A free NYC Open Data app token, for higher rate limits. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_restroomsA | Finds operational NYC public restrooms near a given point, sorted by distance ascending. latitude/longitude may both be omitted to search from your current location, detected automatically (precise on-device location if available, otherwise an approximate IP-based guess) - only used when that location is within New York City, otherwise this tool returns an error asking for explicit coordinates instead. Radius defaults to 800m and is clamped to a 5000m maximum. Set open_now to filter to restrooms currently open (restrooms with unparseable hours are kept, marked "unknown", rather than guessed at). |
| get_restroom_statusA | Looks up one NYC public restroom by name or by nearest coordinates, and - where NYC Parks inspection data is available for it - reports its most recent condition ratings. Only restrooms operated by NYC Parks are covered by inspection data; other operators (libraries, automated public toilets, private operators) will report status "no_inspection_data". |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct roles: find_restrooms discovers restrooms by proximity and open status, while get_restroom_status looks up a single restroom's detailed condition. No overlap or ambiguity.
Both tools follow a consistent verb_noun snake_case pattern: find_restrooms and get_restroom_status. This is perfectly predictable.
With only 2 tools, the server sits at the borderline lower end of the scale. The narrow domain could justify it, but the small surface area feels thin compared to typical MCP servers.
The two tools cover the essential workflow of finding restrooms and checking their status. A few minor gaps exist, such as no way to list all restrooms or filter by amenities, but these are not core dead ends for the stated purpose.