Loading ToolBench
NYC Real Estate Due Diligence MCP Server — provides property intelligence tools powered by NYC public data for real estate investors, attorneys, and brokers
NYC Property Intel demonstrates solid definition quality with consistent naming conventions, descriptive tool purposes, and properly typed schemas. All 14 tools follow a clear verb_noun pattern (get_*, search_*). Descriptions are substantive and context-appropriate for a real estate domain. However, parameter descriptions are minimal in many cases, output schemas are not explicitly documented in the visible code, and there is no evidence of error handling guidance or structured output documentation. The tools are well-motivated and domain-coherent, but fall short of A-grade rigor.
Comprehensive single-call analysis running sub-queries for PLUTO profile, sales history, ACRIS deeds, ownership, tax assessment, mortgages, 311 complaints, and comparable sales. Note: violations, permits, rent stabilization, and evictions may return null due to materialized-view limitations; use dedicated tools for authoritative data.
Retrieve 311 service request complaints for a property from NYC's complaint tracking system
Retrieve DOB job filings and building permits including new construction, alterations, and demolitions
Retrieve DOB (Department of Buildings) pre-violation complaints for a property
Retrieve marshal eviction records (residential and commercial) from NYC eviction tracking system
Retrieve FDNY fire incident history for the property's zip code area
Parameter descriptions are minimal or absent. Most tools accept only 'bbl' parameter with a brief description, but do not document constraints, valid formats, error conditions, or when to use alternatives (e.g., when to use address vs BBL for lookup_property). LLM cannot infer the correct invocation pattern.
Output schemas are not documented in the visible tool definitions. Tool responses are expected to return structured data (violations, sales history, complaints, etc.) but the shape, field names, data types, and required vs optional fields are not declared. LLMs cannot plan downstream calls or extract fields reliably.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | <=2025-11-25 | v2 |
Retrieve tenant complaints filed with HPD (Housing Preservation Department) for a property
Retrieve tax liens, mortgage records, and other property encumbrances from DOF and ACRIS
Retrieve NYPD crime complaints within a 300m radius of a property location
Retrieve sales history from DOF rolling sales and ACRIS deed transfers showing ownership changes and transaction prices
Retrieve HPD housing violations, DOB building violations, and ECB/OATH penalties for a property by BBL
Query NYC RGB (Rent Guidelines Board) rent stabilization registry for a property
Resolve an address or BBL to canonical property details including owner name, zoning, lot dimensions, tax class, and building profile from NYC PLUTO database
Find comparable property sales in the same zip code and building class to benchmark market value
No pagination or result-limiting strategy is documented for tools that may return large result sets (get_property_history, search_comps, get_311_complaints, etc.). These tools do not declare limit/offset parameters or explain how many results are returned. A single property may have dozens of complaints or historical transactions; returning all could exhaust context.
Error handling and recovery guidance is absent. Tools do not document what errors can occur (e.g., invalid BBL format, property not found, API timeout) or what the LLM should do (retry? use alternative tool? ask user?). No error classification (retryable vs user-fixable vs fatal).
lookup_property accepts both address and BBL but does not document the expected format for each. BBL is stated as 'X-XXXXX-XXXX' but no examples or validation rules are provided. Address format is not specified (street only? with city/state/zip?). This ambiguity will cause LLM invocation errors.
analyze_property includes a disclaimer that 'violations, permits, rent stabilization, and evictions may return null due to materialized-view limitations' but does not advise the LLM to call the dedicated tools instead. This creates ambiguity: should the LLM trust the null response or retry with the dedicated tool?
Parameter 'months_back' and 'years_back' are numeric but no bounds are documented (min, max, default). An LLM could pass months_back=999999 or years_back=-1. Ranges should be explicit in parameter descriptions.