nyrezone-mcp

Overview Schema Source Related Servers Discussions Admin

Look up an NYC tax lot

lookup_lot

Read-onlyIdempotent

Look up an NYC tax lot by street address or 10-digit BBL to retrieve recorded zoning districts, MapPLUTO FAR fields, lot and building area, year built, and land use.

Instructions

Look up one NYC tax lot by street address OR 10-digit BBL (borough-block-lot). Returns recorded zoning district(s), MapPLUTO FAR fields, lot and gross building area, year built and land use via NYRezone. Does not determine development capacity, unused development rights, applicable FAR or zoning compliance; deprecated calculation fields are null. 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.

Input Schema

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".

Output Schema

Name	Required	Description
`lot`	Yes
`source`	Yes
`resolved_from`	Yes
`district_pages`	Yes
`full_report_url`	Yes	Legacy field name: public lot map URL; no paid report data
`matched_address`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.2.0Oct 31, 2026
- addedOutput schema / properties / full_report_url / description
```
Added value: +"Legacy field name: public lot map URL; no paid report data"
```
- addedOutput schema / properties / lot / properties / unused_floor_area / properties / allowed_floor_area_sqft / description
```
Added value: +"Deprecated; legally permitted floor area is not determined."
```
- changedOutput schema / properties / lot / properties / unused_floor_area / properties / allowed_floor_area_sqft / type
```
Previous value: -[
-  "number",
-  "null"
-]New value: +"null"
```
- addedOutput schema / properties / lot / properties / unused_floor_area / properties / estimate_sqft / description
```
Added value: +"Deprecated; capacity is not determined from recorded parcel data."
```
- changedOutput schema / properties / lot / properties / unused_floor_area / properties / estimate_sqft / type
```
Previous value: -[
-  "number",
-  "null"
-]New value: +"null"
```
- addedOutput schema / properties / lot / properties / unused_floor_area / properties / governing_far / description
```
Added value: +"Deprecated; applicable FAR is not determined."
```
- changedOutput schema / properties / lot / properties / unused_floor_area / properties / governing_far / type
```
Previous value: -[
-  "number",
-  "null"
-]New value: +"null"
```
- addedOutput schema / properties / lot / properties / unused_floor_area / properties / overbuilt / description
```
Added value: +"Deprecated; zoning compliance is not determined from gross building area."
```
- changedOutput schema / properties / lot / properties / unused_floor_area / properties / overbuilt / type
```
Previous value: -"boolean"New value: +"null"
```
First observedv0.1.0Oct 16, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the read-only/idempotent annotations, it discloses null semantics for deprecated calculation fields, error-on-ambiguity behavior, and a hard data exclusion ('Owner and assessment data are never returned'). These are behavioral facts not present in the annotations or schema.

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?

Front-loaded with purpose, then return contents, then exclusions, then input rules, then error behavior. Every sentence carries a distinct constraint; there is no padding or repetition of the schema.

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?

With an output schema present, the description needn't document return shape, and it still covers inputs, error cases, nullability, and excluded data. Nothing an agent needs to invoke this correctly is missing.

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 baseline is 3, but the description adds a constraint the schema does not encode: exactly one of the two optional parameters must be supplied. It also reinforces the address format (leading house number, include borough).

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?

States a specific verb and resource ('look up one NYC tax lot') and enumerates exactly what is returned (zoning districts, FAR fields, lot/building area, year built, land use). The two accepted keys (address or BBL) make it immediately distinguishable from the zoning-district siblings.

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?

Explicitly bounds usage: 'Provide exactly one of address or bbl', address must start with a house number and include borough, and ambiguous addresses error rather than guess. It also lists what it does not do (development capacity, unused rights, compliance). It stops short of naming when to prefer the sibling zoning-district tools, which is the only routing gap.

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

Deploy Server