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., "@nyc-rent-check Check 2835 Barker Ave in the Bronx for red flags."
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.
An MCP server for NYC apartment hunters. Give it an address and it checks the city's public records: HPD violations, bed bug filings, 311 heat and noise complaints, and DOB complaints. Then it tells you what to worry about.
No API keys. Read-only. Data comes straight from NYC Planning GeoSearch and NYC Open Data.
claude mcp add nyc-rent-check -- npx -y github:Sayemnyc/nyc-rent-check-mcpFor other MCP clients (Claude Desktop, Cursor, etc.), add this to the client's MCP config:
{ "mcpServers": { "nyc-rent-check": { "command": "npx", "args": ["-y", "github:Sayemnyc/nyc-rent-check-mcp"] } } }Requires Node 18+.
Related MCP server: streeteasy-mcp
Tool | What it does |
| Resolves an address to its BBL (tax lot) and BIN (building ID) using NYC Planning GeoSearch. |
| Returns everything in one call: HPD violations (open and closed, by class A/B/C, plus rent-impairing and the latest open Class C items), annual bed bug filings, 311 heat/hot water and noise complaints from the last 24 months, and DOB complaints. |
| Gives a plain-English verdict ( |
If an address can't be resolved, the tool says why. For example: no house number, no NYC match, or the same address exists in more than one borough. In that last case, add the borough or ZIP.
You: I'm looking at an apartment at 2835 Barker Ave in the Bronx. Anything I should know?
Claude: (calls
red_flags) High concern. City records show serious, ongoing problems:
326 heat/hot water complaints to 311 in the last two years, the most recent on Oct 11, 2026.
121 open Class C violations. Class C means immediately hazardous. The newest is a broken self-closing entrance door, and there are open mouse and roach infestation orders in individual apartments.
221 open Class B (hazardous) violations.
The landlord's bed bug filings show 1 infested unit in 2023–24 and none in the latest year. Ask how heat is handled in winter, and check the unit for pests during your viewing.
You: Compare that to 350 5th Ave.
Claude: (calls
red_flags) That's the Empire State Building, which is commercial, so there's no HPD history at all. The only flags are 96 noise complaints (mostly commercial and street noise) and 1 open DOB complaint.
These numbers are live, so you'll see different counts when you run it.
All datasets were checked on data.cityofnewyork.us:
Data | Dataset | Matched by |
HPD Housing Maintenance Code Violations | BIN | |
Bedbug Reporting (annual landlord filings) | BIN | |
311 Service Requests, 2020 to present | BBL | |
DOB Complaints Received | BIN |
311 only records the tax lot (BBL), so on lots with several buildings the 311 counts cover the whole lot. HPD violation classes: A = non-hazardous, B = hazardous, C = immediately hazardous, I = info/order.
Queries use server-side aggregation ($select/$group), so each report is 5 small requests plus 1 geocode. Responses are cached in memory for 10 minutes, so calling building_report and then red_flags on the same address doesn't re-fetch. The server backs off and retries on HTTP 429 or 5xx. If you're doing heavy use, you can set a free Socrata app token for higher limits:
claude mcp add nyc-rent-check -e SOCRATA_APP_TOKEN=yourtoken -- npx -y github:Sayemnyc/nyc-rent-check-mcpnpm install
npm test # builds, then runs live tests against two real addresses
npm start # runs the stdio serverPublic records lag reality and miss a lot. A clean record isn't a guarantee, and a messy one in a 500-unit building may matter less than it looks. The red_flags weights are a simple heuristic, not legal or professional advice.
MIT
Full public-records report for an NYC residential building: HPD violations (open and closed, by class A/B/C), annual bed bug filings, 311 heat/hot water and noise complaints from the last 24 months, and DOB complaints.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | NYC street address with house number, ideally with borough or ZIP, e.g. '2835 Barker Ave, Bronx' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds substantive scope context the annotations cannot convey: which datasets are aggregated (HPD violations with A/B/C classes, bed bug filings, 311 complaints), and an explicit 24-month window for 311 data. It stops short of noting latency, cost, or behavior for unmatched addresses, which matters for a multi-source aggregation call.
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?
One front-loaded sentence that identifies the resource first and then enumerates contents; every listed item is load-bearing information about the return payload. No filler or repetition.
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 no output schema, the description must carry the burden of explaining what comes back, and it does so by enumerating the record categories and the 24-month window. Minor gaps remain around response size/shape and behavior when the address is ambiguous or not found.
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?
There is a single parameter with 100% schema description coverage, and the schema already supplies the format guidance and an example address. The description adds nothing beyond that, so the baseline of 3 applies.
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?
The description names the resource (full public-records report for an NYC residential building) and enumerates exactly which record sets are included, which is far more specific than a generic 'get building data'. It doesn't explicitly contrast itself with the siblings lookup_building or red_flags, so an agent must infer the difference from the breadth of the enumeration.
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 only implied: the breadth of the enumeration suggests this is the comprehensive option versus a narrower lookup, but no when-to-use condition, prerequisite, or alternative tool is named. With two relevant siblings present, the absence of any routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve an NYC address to its official BBL (tax lot) and BIN (building ID) via NYC Planning GeoSearch.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | NYC street address with house number, ideally with borough or ZIP, e.g. '2835 Barker Ave, Bronx' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile and the fact that it hits external data. The description usefully adds that the lookup goes through NYC Planning GeoSearch and what identifiers come back, which is real context beyond the annotations. It stops short of noting failure/no-match behavior or rate limits on the external service.
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?
A single sentence, front-loaded with the verb and outcome, with no filler. Every clause (address, BBL, BIN, GeoSearch) carries 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?
With no output schema, the description does name the returned identifiers and gloss them, which is the key completeness need for a lookup tool. It omits edge behavior (no match, multiple matches, malformed address) and the external-service dependency's practical consequences, but covers the essentials for calling it.
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% and the single address parameter already documents format and an example ('2835 Barker Ave, Bronx'). The description adds nothing about the parameter, so the baseline 3 applies.
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 (resolve) plus the resource (NYC address) and the concrete outputs (BBL tax lot, BIN building ID) via a named upstream service. This is far more specific than a tautology, but it never distinguishes itself from siblings building_report or red_flags, so an agent must infer the relationship.
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?
There is no when-to-use, when-not-to-use, or alternative comparison. It does not tell the agent whether this is a prerequisite step for building_report, or what to do if the address is ambiguous. Only the purpose implies usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plain-English verdict on an NYC building with the top 3 concerns from city records. Use this for a quick 'should I worry?' answer.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | NYC street address with house number, ideally with borough or ZIP, e.g. '2835 Barker Ave, Bronx' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the bar is lower. The description adds real value beyond them by disclosing the data source (city records) and the return shape (a plain-English verdict capped at 3 concerns), which matters because there is no output schema. It says nothing about freshness, coverage limits, or what happens when records are missing.
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 zero filler; the deliverable (verdict + top 3 concerns) is front-loaded before the usage cue. Every clause earns its place.
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 read-only tool, the definition covers the essentials: what it returns, that it is capped at 3 items, and that it is a quick triage signal. With no output schema, a brief note on what the 'concerns' actually are (violations, complaints, etc.) would close the remaining 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?
There is a single parameter with 100% schema description coverage, including a concrete address example, so the schema carries the semantics. The description adds nothing about the address argument, so the baseline 3 applies.
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?
The description gives a specific verb+resource: it produces a plain-English verdict on an NYC building drawn from city records, and it scopes the output to the top 3 concerns. That is far more concrete than the title alone, though it never names lookup_building or building_report, so the agent must infer the distinction from the 'top 3 / quick' framing rather than being told.
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?
It states a clear use context: 'Use this for a quick "should I worry?" answer,' which routes triage-style questions here. It stops short of explicit exclusions or naming the fuller-report alternative, so the when-not case is left implicit.
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.0building_reportlookup_buildingred_flagsScored across 3 tools
Each tool has a clearly distinct role: lookup_building resolves an address, building_report returns full public records, and red_flags provides a quick top-concerns verdict. The descriptions explicitly frame red_flags as a summary, so overlap with the full report is unlikely to cause misselection.
All names use snake_case, which is consistent casing, but the grammatical pattern is mixed: lookup_building is verb_noun, while building_report and red_flags are noun phrases. The names remain readable but do not follow one predictable convention.
Three tools is on the lean side but well-scoped for a focused NYC building-check service, with each tool serving a clear, non-redundant purpose. It avoids both bloat and excessive fragmentation.
The set covers the core workflow: resolve an address, pull the full public-records report, and get a plain-English red-flag summary. Minor gaps exist, such as direct rent-stabilization or eviction-record checks, but the main rental-risk questions are addressed.
Building intelligence for NYC, LA, Chicago rentals: violations, 311, reviews, rents, landlords.
Building-permit verdicts by address, with cited records. SF, Seattle, Austin, NYC. Pay per call.
Agent-ready NYC public records. Hosted, source-backed civic data organized around durable anchors.
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
