Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nyrezone-mcp What's the zoning and unused FAR for 123 Atlantic Ave, Brooklyn?"
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.
Read-only MCP server that gives AI assistants NYC zoning facts from the public data on NYRezone: which zoning district a tax lot is in, built vs. allowed FAR, lot and building area, an estimated unused floor area, and the rules for each zoning district.
It exposes only data that is already public and unauthenticated. No owner names, no assessed values, no paid report data, no account access.
Requires Node 20+.
npx -y nyrezone-mcpAdd to claude_desktop_config.json:
{
"mcpServers": {
"nyrezone": { "command": "npx", "args": ["-y", "nyrezone-mcp"] }
}
}claude mcp add nyrezone -- npx -y nyrezone-mcpRelated MCP server: Korean Land MCP
All tools are read-only (readOnlyHint: true).
Tool | Input | Returns |
|
| Zoning district(s), overlays and special districts, built FAR vs. maximum FAR, lot area, building area, estimated unused floor area, year built, land use. Ambiguous or unknown input returns an error, never a guess. |
|
| FAR, height rules and bonuses as NYRezone publishes them, citywide lot counts, average built FAR. Unknown code returns the list of valid codes. |
| optional | The 51 districts NYRezone documents, each with its district-family description. |
Every result ends with a source line (MapPLUTO release as stated by NYRezone, the matching nyrezone.com page, and for lots a Full report link) and a disclaimer.
Not included: a borough-level "underbuilt" summary. NYRezone publishes that only as web pages, not as a data endpoint.
lookup_lot with bbl: "3052410015" returns, in part: zoning R7A, lot area 4,675 sq ft, building area 2,606 sq ft, built FAR 0.56 against a 4.0 residential maximum, and an estimated 16,094 sq ft unused.
maximum FAR x lot area - existing building area, using MapPLUTO's residential FAR (commercial or community-facility FAR if there is no residential FAR). It is a screening number only. It does not account for street width, special districts, overlays, split-zoned lots, mapped streets, or City of Yes / Universal Affordability Preference bonuses. If the building already exceeds the maximum, the tool reports 0 and says the lot is over-built.
nyrezone.com (/api/pluto, /zoning, /zoning/<code>, /methodology): lot data and district pages. Data is NYC DCP MapPLUTO; the release is read from NYRezone's own methodology page.
NYC Planning Labs Geosearch (geosearch.planninglabs.nyc): used only to turn a street address into a BBL, because NYRezone has no address endpoint. This is the one third-party host; the address you ask about is sent to it. BBL lookups and district lookups never contact it.
The owner name and owner type that NYRezone's lot API returns are dropped in this server and never appear in a tool result.
Descriptive User-Agent (nyrezone-mcp/<version> (+repo URL)).
Requests are serialized, at least 1 second apart, capped at 20 upstream requests per minute, with a 10 second timeout and a 2 MB response cap.
Responses are cached in memory for 1 hour (not persisted).
Input is validated before any request: addresses 5-150 characters starting with a house number; BBLs must be 10 digits starting 1-5. Everything sent upstream is URL-encoded.
Informational only. Not legal, architectural, or zoning-compliance advice. Confirm with the NYC Department of City Planning or a licensed professional before relying on it. Not affiliated with the City of New York.
npm install
npm test # builds, then runs node:test against recorded fixtures (no live network)Fixtures in fixtures/ are recorded public responses; the lot fixtures keep the raw owner fields on purpose so the tests prove they are dropped. Environment variables NYREZONE_MCP_BASE_URL, NYREZONE_MCP_GEOSEARCH_URL and NYREZONE_MCP_MIN_INTERVAL_MS exist for the end-to-end test only.
MIT. See LICENSE.
Get the rules NYRezone publishes for one NYC zoning district code (e.g. R6A, C4-2, M1-2/R6A): max FAR, base and maximum height, bonuses, citywide lot counts and average built FAR. Height/setback detail is only what NYRezone publishes for that district. An unknown code returns the list of valid codes.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Zoning district code such as R6A, R7-2, C4-2 or M1-2/R6A (case-insensitive). |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| code | Yes | |
| rules | Yes | |
| stats | Yes | |
| source | Yes | |
| summary | Yes | |
| boroughs | Yes | |
| rules_note | Yes | |
| dataVintage | Yes | |
| dataCheckedOn | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive/openWorld, but the description adds real behavioral context: the exact data scope covered and the caveat that height/setback detail is limited to what NYRezone publishes. The unknown-code fallback behavior is also disclosed, which is useful for an open-world tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with what is returned, then the data caveat, then the error path. No filler, though the payload enumeration is slightly list-heavy for a one-parameter call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be spelled out, yet the description still orients the agent on fields and adds the null/unknown-code path. Complete enough for a simple lookup; only the sibling-routing is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter, so the baseline is 3. The description repeats the same example codes (R6A, C4-2, M1-2/R6A) already given in the schema and adds no new syntax, format, or case-handling detail beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('Get') plus resource ('the rules NYRezone publishes for one NYC zoning district code'), and it enumerates the payload (max FAR, base/maximum height, bonuses, lot counts, average built FAR). The scope word 'one ... code' implicitly separates it from list_zoning_districts, but no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (supply a district code to get its rules) and the description adds an error-path hint that an unknown code returns valid codes. It never states when to prefer this over list_zoning_districts or lookup_lot, so guidance stays at implied-usage level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the NYC zoning district codes NYRezone documents, each with a one-line summary (its district family description). Optionally filter by family, e.g. R6 or C4.
| Name | Required | Description | Default |
|---|---|---|---|
| family | No | Optional family filter such as R6, C4, M1. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| source | Yes | |
| districts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety and idempotency profile is fully covered. The description adds only the shape of each result item (a one-line family summary), which is modest context and partly overlapped by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the resource defined first and the optional filter second – well front-loaded. The example values in the second sentence slightly duplicate the schema's examples, a minor redundancy rather than bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, all-optional listing tool with an output schema and full annotation coverage, the essentials are present. It stops short of routing between the sibling tools or indicating what family values exist, which would fully close the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – the 'family' parameter is already documented in the schema with examples (R6, C4, M1). The description restates the same filter and the same example values ('R6 or C4') without adding format or matching semantics above what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('NYC zoning district codes NYRezone documents'), and clarifies what each entry contains ('one-line summary / district family description'). It implicitly separates itself from the singular get_zoning_district sibling via plural enumeration, but never names or contrasts with siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Optionally filter by family' tells the agent how to narrow the list, but there is no guidance on when to prefer this over get_zoning_district or lookup_lot. Usage is implied (enumerate districts / browse families) rather than stated with alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one NYC tax lot by street address OR 10-digit BBL (borough-block-lot). Returns zoning district(s), built vs. allowed FAR, lot and building area, an estimated unused floor area, year built and land use, from MapPLUTO via NYRezone. Provide exactly one of address or bbl. Addresses must start with a house number and should include the borough; an ambiguous or unknown address returns an error instead of a guess. Owner and assessment data are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
| bbl | No | 10-digit BBL, e.g. 3052410015 (1 Manhattan, 2 Bronx, 3 Brooklyn, 4 Queens, 5 Staten Island). | |
| address | No | Street address starting with a house number, e.g. "1187 Ocean Ave, Brooklyn". |
| Name | Required | Description |
|---|---|---|
| lot | Yes | |
| source | Yes | |
| resolved_from | Yes | |
| district_pages | Yes | |
| full_report_url | Yes | |
| matched_address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations (which only cover readOnly/idempotent/openWorld/destructive): it discloses data provenance (MapPLUTO via NYRezone), the explicit error-instead-of-guess behavior on ambiguous addresses, and a hard data-exclusion guarantee that owner and assessment data are never returned. These are exactly the operational traits an agent cannot infer from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, no filler, with the key constraint (exactly one key) front-loaded before the format rules and the return/exclusion details. Every sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read lookup with an output schema, the definition covers identity, inputs, format rules, error behavior, and data boundaries, so an agent can invoke it correctly without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the schema documents both fields; the description still contributes the mutual-exclusivity constraint ('exactly one of address or bbl') that no schema-level oneOf encodes, plus the house-number prefix requirement. It adds real selection semantics beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ('Look up one NYC tax lot') and immediately scopes it by the two accepted keys (street address OR 10-digit BBL). It also enumerates the returned fields and names the data source, which cleanly separates it from the sibling zoning-district tools that answer a different question.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete selection rule ('Provide exactly one of address or bbl') plus address formatting requirements and the failure mode for ambiguous/unknown addresses. It stops short of naming an alternative tool for when a lot lookup is the wrong choice, but the usage context is otherwise unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_zoning_districtlist_zoning_districtslookup_lotScored across 3 tools
Each tool targets a distinct object and action: lookup_lot retrieves a specific lot, get_zoning_district returns rules for one district code, and list_zoning_districts enumerates available codes. There is no overlap that would cause an agent to misselect.
All three names follow a verb_noun snake_case pattern (lookup_lot, get_zoning_district, list_zoning_districts). The verbs (lookup/get/list) are distinct and clearly map to their operations.
Three tools is lean but well-scoped for a read-only zoning/lot lookup service. Each tool earns its place, though it sits near the thin end of the acceptable range.
The core lookup lifecycle (resolve a lot, inspect a district's rules, enumerate districts) is covered with no dead ends. Minor gaps exist, such as no way to search lots by district or perform batch/area queries, but the primary use cases are handled.
Zoning, ADU eligibility, flood zone, setbacks, and buildability intelligence for U.S. parcels.
Human-reviewed zoning answers with ordinance citations for covered US municipalities.
Zoning, homes per lot, short-term rentals, tax and flood for any property in Austin and Nashville.
Zoning, parcel, and development feasibility for a street address in Canada and the US.
