How do I use NYC Property Data MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@NYC Property Data MCP Server Find recent sales in East Village under $10M" 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.

NYC Property Data MCP Server

by deverseli800

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

NYC Property Data MCP Server

A Model Context Protocol (MCP) server that provides Claude with access to NYC public property data. Query property details, sales history, comparable sales, tax benefits, and rent stabilization analysis using natural language.

No API keys required - all data sources are free and public.

Features

🏢 Property Lookup - Get detailed property info including owner, units, year built, zoning, and assessed values
💰 Sales Search - Find recent property sales with price per unit and price per sqft calculations
📊 Comparable Sales - Find similar properties for valuation analysis with implied value estimates
🏛️ Tax Benefits - Look up 421a, J-51, ICAP, STAR and other exemptions/abatements
🏠 Rent Stabilization Analysis - Automatic analysis of likely rent-stabilized units based on year built, unit count, and tax benefits

Related MCP server: RentCast MCP Server

Data Sources

Dataset	Source	Description
PLUTO	NYC Open Data	Property tax lot data - owner, units, zoning, assessments
Rolling Sales	NYC Open Data	Last 12 months of property sales
Property Exemptions	NYC Open Data	Tax exemptions by property
Property Abatements	NYC Open Data	Tax abatements (421a, J-51, etc.)

Installation

Prerequisites

Node.js 18+
Claude Desktop app

Install from npm

npm install -g cre-property-mcp

Or clone and build locally

git clone https://github.com/deverseli800/cre-public-data-mcp.git
cd cre-public-data-mcp
npm install
npm run build

Configuration

Claude Desktop Setup

Edit the Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Windows: %APPDATA%\Claude\claude_desktop_config.json

If installed globally via npm:

{
  "mcpServers": {
    "property": {
      "command": "property-mcp"
    }
  }
}

If running from local build:

{
  "mcpServers": {
    "property": {
      "command": "node",
      "args": ["/path/to/property-mcp/dist/index.js"]
    }
  }
}

Zero-install with npx:

{
  "mcpServers": {
    "property": {
      "command": "npx",
      "args": ["-y", "cre-property-mcp"]
    }
  }
}

After editing, quit Claude Desktop completely (Cmd+Q on macOS) and reopen.

Running Locally

Development

# Install dependencies
npm install

# Build TypeScript
npm run build

# The server runs via stdio (used by Claude Desktop)
# For testing, you can run directly:
node dist/index.js

Viewing Logs

The server logs to stderr, which Claude Desktop captures:

# macOS
tail -f ~/Library/Logs/Claude/mcp-server-property.log

# Or check Claude Desktop's developer console

Tools Reference

`get_property`

Get detailed property information by address.

Parameters:

city (required): "nyc"
address (required): Street address
borough: NYC borough (manhattan, bronx, brooklyn, queens, staten_island)

Example:

"Look up 522 East 5th Street Manhattan"

Returns:

Address, BBL, coordinates
Owner name
Units (residential and total)
Year built, building class, zoning
Assessed values (land, total, exempt)
ZOLA map link
Rent stabilization analysis

`search_sales`

Search for recent property sales with filters.

Parameters:

city (required): "nyc"
borough: NYC borough
neighborhood: e.g., "EAST VILLAGE", "HARLEM"
min_price / max_price: Price range
min_units / max_units: Unit count range
building_class: "C" (walk-up), "D" (elevator), etc.
date_from / date_to: Date range (YYYY-MM-DD)
whole_buildings_only: Exclude unit sales (default: true)
limit: Max results (default: 10, max: 50)

Example:

"Find 5 recent elevator building sales over $5M in the East Village"

Returns:

Sale price, date, address
Units, sqft, year built
price_per_unit and price_per_sqft calculations
Owner, zoning
ZOLA map link

`search_comps`

Find comparable sales for valuation analysis.

Parameters:

city (required): "nyc"
address (required): Subject property address
borough (required): Subject property borough
limit: Number of comps (default: 10)
building_class: Override auto-detected class
include_adjacent_neighborhoods: Include nearby areas (default: true)

Example:

"Find comparable sales for 522 East 5th Street Manhattan"

Returns:

Subject property details
Ranked comparable sales with similarity scores
Average price per unit and price per sqft
Implied values for subject property

`get_sale_history`

Get all recorded sales for a specific property.

Parameters:

city (required): "nyc"
address (required): Street address
borough: NYC borough

Example:

"What's the sale history for 100 Gold Street Manhattan?"

`search_properties`

Search for properties (not sales) matching criteria.

Parameters:

city (required): "nyc"
borough: NYC borough
min_units / max_units: Unit count range
building_class: Building type
zoning: Zoning district (e.g., "R7", "C6")
min_year_built / max_year_built: Year range
limit: Max results

Example:

"Find walk-up buildings with 10+ units in Brooklyn built before 1940"

`get_tax_benefits`

Look up tax exemptions and abatements for a property.

Parameters:

city (required): "nyc"
address: Street address
borough: NYC borough
Or: borough_code, block, lot (direct BBL lookup)

Example:

"What tax benefits does 522 East 5th Street Manhattan have?"

Returns:

All exemptions with codes and values
All abatements with amounts and dates
Flags: has_421a, has_j51, has_icap, has_star
Human-readable summary

Rent Stabilization Analysis

Every property lookup includes a rent_info object with stabilization analysis:

{
  "rent_info": {
    "likely_stabilized": true,
    "stabilization_reasons": [
      "Pre-1974 building (1900) with 10 units",
      "Receives J-51 tax abatement"
    ],
    "confidence": "high",
    "notes": [
      "Individual units may be deregulated through high-rent vacancy",
      "Verify with DHCR for definitive unit counts"
    ]
  }
}

Stabilization Rules Applied:

Buildings with 6+ units built before January 1, 1974
Buildings receiving 421a tax exemption
Buildings receiving J-51 tax abatement
NYCHA buildings excluded (federal rules apply)
Condo/co-op buildings noted separately

Example Queries

"Look up the property at 100 Gold Street in Manhattan"

"Find 10 recent multifamily sales in Williamsburg over $2M"

"What's the sale history for 123 E 7th Street Manhattan?"

"Find comparable sales for 522 East 5th Street Manhattan"

"Does 200 East 10th Street Manhattan have any tax abatements?"

"Search for elevator buildings with 20+ units in Harlem"

"Find walk-up buildings in the East Village built before 1920"

Building Classes

Code	Description
A	One-family dwellings
B	Two-family dwellings
C	Walk-up apartments
D	Elevator apartments
R	Condominiums
S	Residences - multiple use

Limitations

NYC Rolling Sales only contains the last 12 months of sales
Rent stabilization analysis is an estimate - verify with DHCR for official status
Tax benefits data may lag behind current status

Troubleshooting

"Property not found"

Check address format (e.g., "522 East 5th Street" not "522 E 5th St")
Verify borough is correct
Try without apartment/unit numbers

"No sales found"

Expand date range
Try broader neighborhood search
Check if building class filter is too restrictive

Server not connecting

Quit Claude Desktop completely (Cmd+Q) and reopen
Check config file JSON syntax
Verify node path in config

View logs

tail -f ~/Library/Logs/Claude/mcp-server-property.log

Contributing

Contributions welcome! Areas of interest:

Philadelphia data source implementation
Additional NYC data sources (ACRIS, HPD violations)
Performance optimizations
Additional analysis tools

License

MIT

Acknowledgments

Data provided by:

Available Tools

7 tools

get_deed_partiesA

Look up buyer (grantee) and seller (grantor) for a NYC property from ACRIS deed records. Use when the user specifically asks who bought or sold a property.

ParametersJSON Schema

Name	Required	Description
`city`	Yes	City
`address`	Yes	Street address
`borough`	No	NYC borough

TDQS

A3.9/5.0

Behavior3/5

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

There are no annotations, so the description carries the full burden. It does disclose what the tool returns (buyer/grantee and seller/grantor) and the data source (ACRIS deed records). However, it implies a read-only lookup without explicitly stating it, and it fails to address the apparent discrepancy between 'NYC property' and the schema's 'philadelphia' enum value, leaving room for confusion about scope.

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?

Two sentences with the primary action front-loaded. No filler or repetition. Every clause contributes, and the 'Use when...' clause is a practical addition. This is appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 3 parameters, no output schema, and no annotations. The description addresses purpose and when-to-use, but does not explain return format, error behavior, or the city/borough relationship. Given the missing structured metadata, the description should be more explicit about edge cases and the mismatch in the city enum.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds context that the tool works with deed records, but it does not elaborate on how to format the address or when the optional borough parameter should be included. The city enum discrepancy is not clarified, so the description adds minimal value beyond the schema.

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?

The description uses a specific verb and resource: 'Look up buyer (grantee) and seller (grantor) for a NYC property from ACRIS deed records.' This clearly distinguishes it from sibling tools like get_property or search_sales, which are broader. The only minor confusion is the schema allows 'philadelphia' while the description says 'NYC,' but the core purpose is unambiguous.

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?

The description states an explicit trigger: 'Use when the user specifically asks who bought or sold a property.' This gives clear context for when to select the tool. However, it does not mention alternatives, exclusions, or cases where it should not be used (e.g., when a broader property search is needed), so it falls short of a 5.

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

get_propertyGet PropertyA

Get detailed property information including owner, units, zoning, coordinates, and rent stabilization analysis. Result displays on an interactive map.

ParametersJSON Schema

Name	Required	Description
`city`	Yes	City
`address`	Yes	Street address to search
`borough`	No	NYC borough

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations to rely on, the description discloses key behaviors: it lists the types of data returned and states the result 'displays on an interactive map.' This goes beyond a minimal 'get' statement, though it stops short of explicitly noting read-only status or potential edge cases.

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?

The description is two sentences, front-loaded with the verb and resource, and every word adds value. No filler or redundant repetition of the title 'Get Property.'

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple get tool with 3 parameters and no output schema, the description covers the core purpose and output presentation. It lacks explicit differentiation from sibling tools but is otherwise complete for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage for all three parameters, so a baseline of 3 applies. The description mentions fields like owner and zoning but does not add meaningful parameter-level syntax or relationships beyond the schema's one-line labels.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the tool's function: 'Get detailed property information including owner, units, zoning, coordinates, and rent stabilization analysis.' This distinguishes it from sibling search tools by emphasizing a single property's comprehensive detail, though it does not explicitly name siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage—call this when you need detailed data for a specific property—but provides no explicit guidance on when to choose it over search_properties, search_sales, or other siblings. No exclusions or alternative scenarios are mentioned.

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

get_sale_historyB

Get all recorded sales for a specific property.

ParametersJSON Schema

Name	Required	Description
`city`	Yes	City
`address`	Yes	Street address
`borough`	No	NYC borough

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states 'get all recorded sales', which essentially restates the purpose without explaining return format, sorting, pagination, or matching semantics. This is insufficient for a tool with no other behavioral context.

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?

The description is a single, direct sentence with no unnecessary words. It is concise and front-loaded, effectively communicating the core action without noise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple get-by-address tool, the description is minimally sufficient, but the absence of an output schema and annotations means it could explain what 'recorded sales' includes (e.g., dates, prices, parties). This is a notable gap, so the description is adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameters with descriptions (city, address, borough) and enums for city and borough. The tool description adds no additional parameter semantics, but the high schema coverage means the parameters are already documented well enough, warranting the baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves all recorded sales for a specific property, using a specific verb and resource. It does not explicitly distinguish from the sibling tool 'search_sales', but the phrase 'for a specific property' gives scope that hints at the difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'search_sales' or 'search_properties'. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent to infer when this tool is appropriate.

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

get_tax_benefitsB

Get tax exemptions and abatements for a NYC property. Returns 421a, J-51, ICAP, STAR benefits.

ParametersJSON Schema

Name	Required	Description
`lot`	No	Lot number if known
`city`	Yes	City
`block`	No	Block number if known
`address`	No	Street address to search
`borough`	No	NYC borough
`borough_code`	No	Borough code (1-5) if known

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool returns certain benefit types, which is essentially a restatement of output. It does not disclose any side effects, prerequisites, or behaviors such as how property identification works or what happens if no benefits exist. The mismatch between 'NYC' and the city enum further obscures behavior.

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?

The description is two short sentences, front-loading the core action and then listing the returned benefit types. It contains no redundant wording or unnecessary details, achieving high efficiency for its limited scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description does not adequately explain how to construct a query (e.g., address vs. block/lot) or how to handle the Philadelphia option, and it lacks output schema to clarify the response structure. This makes it insufficiently complete for a tool with six parameters and no structured output schema, especially given the NYC/Philadelphia ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides descriptions for all six parameters (100% coverage), so the baseline is 3. The description adds no parameter-specific meaning and instead introduces a potential conflict by insisting on 'NYC' while the schema permits both nyc and philadelphia. This could mislead an agent on the valid values for the 'city' parameter, reducing the value of the description.

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?

The description clearly states the tool's function with a specific verb ('Get'), a resource ('tax exemptions and abatements'), and lists specific benefit programs (421a, J-51, ICAP, STAR). This distinguishes it from sibling tools like get_property and search_sales. However, the description specifies 'NYC property' while the schema allows city=philadelphia, creating a minor inconsistency that is not addressed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for retrieving tax benefits but provides no explicit guidance on when to use it over alternatives such as search_properties or get_property. There are no exclusions or alternative recommendations, relying on the tool name and description to imply context. This meets the 'implied usage' level but lacks clear context.

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

search_compsSearch CompsA

Find comparable sales for a subject property with similarity scoring. Results display on an interactive map.

ParametersJSON Schema

Name	Required	Description
`city`	Yes	City
`limit`	No	Number of comps (default: 10, max: 50)
`address`	Yes	Subject property address
`borough`	No	NYC borough
`building_class`	No	Override building class filter
`include_adjacent_neighborhoods`	No	Include adjacent neighborhoods (default: true)

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It discloses that results 'display on an interactive map' and mentions 'similarity scoring,' which are useful behaviors. However, it does not clarify read-only nature, data sources, or any limitations, which is a moderate gap given the lack of annotation support.

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?

The description is two sentences, front-loaded with the primary purpose, and includes a notable behavior (interactive map). Every word earns its place with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 6 parameters and no output schema, so the description should compensate for missing return-value details. It mentions map display and similarity scoring but does not describe the returned data structure (e.g., property details, score interpretation). The description is adequate for a straightforward search tool but leaves room for clarifying output semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides (e.g., city, address, borough, limit). It does not name or explain any parameters, but this is acceptable given full schema coverage.

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?

The description clearly states the tool's function: 'Find comparable sales for a subject property with similarity scoring.' This uses a specific verb ('find') and resource ('comparable sales') and distinguishes it from sibling tools like search_sales by emphasizing similarity scoring and subject-property focus.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for property valuation or comps analysis ('for a subject property'), but it does not explicitly state when to use this tool instead of alternatives like search_sales or provide exclusions. Usage context is inferable but not explicit.

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

search_propertiesSearch PropertiesC

Search property database for properties matching criteria. Results display on an interactive map.

ParametersJSON Schema

Name	Required	Description
`city`	Yes	City
`limit`	No
`zoning`	No	Zoning district
`borough`	No	NYC borough
`max_units`	No
`min_units`	No
`neighborhood`	No	Neighborhood name
`building_class`	No
`max_year_built`	No
`min_year_built`	No

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description must carry the behavioral burden, but it only reveals that results display on a map. It does not explain matching semantics, result limits, pagination, or side effects, leaving significant ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no filler, and both sentences contribute useful information. While the brevity is arguably insufficient for the tool's complexity, conciseness itself is well handled.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and ten parameters, the description is far from complete. It fails to describe result format, map data details, defaults, or required constraints beyond the schema, making it inadequate for an agent to fully understand the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover only 40% of the parameters, and the tool description names no parameters or criteria details. With low coverage, the description was expected to compensate but does not, leaving six parameters without any explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches a property database for matching criteria, with results displayed on an interactive map. It does not explicitly differentiate itself from sibling tools like search_sales or search_comps, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or recommend other tools for different search needs.

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

search_salesSearch SalesA

Search for recent property sales in NYC. Filter by neighborhood, price range, building type, and more. Returns sales with price_per_unit and price_per_sqft. Results display on an interactive map.

ParametersJSON Schema

Name	Required	Description
`city`	Yes	City
`limit`	No	Max results (default: 10, max: 50)
`borough`	No	NYC borough
`date_to`	No	Sales on or before this date (YYYY-MM-DD)
`date_from`	No	Sales on or after this date (YYYY-MM-DD)
`max_price`	No	Maximum sale price
`max_units`	No	Maximum residential units
`min_price`	No	Minimum sale price
`min_units`	No	Minimum residential units
`neighborhood`	No	Neighborhood name
`building_class`	No	Building class: C=walk-up, D=elevator, R=condo
`whole_buildings_only`	No	Exclude individual unit sales (default: true)

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that results include price_per_unit and price_per_sqft and display on an interactive map, providing useful output context. However, it does not explicitly confirm that the operation is read-only or mention any rate limits or permissions, though this is largely implied by 'Search'.

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?

The description is three sentences, front-loads the purpose, and each sentence earns its place. It is concise, informative, and avoids unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core purpose, filter capabilities, return fields, and display behavior, which is strong for a search tool. However, it claims 'in NYC' while the schema also supports Philadelphia, and it does not mention the required 'city' parameter or the NYC-only 'borough' field. These gaps are partially addressed by the schema, so the overall completeness is strong but not perfect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameters with descriptive text, so the description adds little beyond what the schema already provides. Mentioning 'neighborhood, price range, building type' simply restates existing schema fields, and 'and more' is vague. The description does not clarify parameter syntax or add new semantics.

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?

The description clearly identifies the tool as a search for recent property sales in NYC, which distinguishes it from sibling tools like search_properties (broader property search) and get_sale_history (historical sales for a specific property). It also mentions filtering options and return fields, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for finding recent sales with filters, but it does not explicitly state when to use this tool over alternatives such as search_comps or search_properties. No exclusions or alternative tool names are mentioned, so the guidance is only implicit.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv1.0.0Aug 2, 2026
- First observedget_deed_parties
- First observedget_property
- First observedget_sale_history
- First observedget_tax_benefits
- First observedsearch_comps
- First observedsearch_properties
- First observedsearch_sales

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored 2026-08-02 16:10 across 7 tools

Disambiguation4/5

Most tools have clear distinct purposes (property lookup, sales search, sale history, tax benefits, deed parties, comps). Minor overlap exists between search_sales and search_comps, as both return sales data, but the comps tool adds similarity scoring and context, reducing confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with 'get_' for specific lookups and 'search_' for query operations. Naming is uniformly snake_case and predictable, making it easy to infer tool behavior.

Tool Count5/5

With 7 tools, the server is well-scoped for a property data domain. Each tool serves a distinct function, and the count is within the ideal range for a focused server.

Completeness4/5

The toolset covers core property data needs: detailed property info, sales search/history, tax benefits, deed parties, and comps. Minor gaps such as property assessments or permits are absent, but the essential workflows for a property data server are well covered.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

nyc-property-intel
io.github.ccedacero
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
Real Estate Government Data
27
Akil MCP - New York City EditionOAuth
io.github.AkilVentures
Agent-ready NYC public records. Hosted, source-backed civic data organized around durable anchors.
Government Data Open Data
1
mcpOAuth
com.skipshit
People and property search for Claude and ChatGPT. Phones, emails, addresses, relatives, properties.
Search Real Estate
2
Borough NYC Real Estate APIOAuth
app.qwady
Search NYC rentals and sales, property details, building data, and market analytics
Real Estate Search Open Data
2

Related MCP Servers

Property MCP Server
Real Estate Search Government Data
noahw345
F
license
Not graded
quality
D
maintenance
Connects Claude AI to real estate data via the ATTOM Data API, enabling property information lookup and analysis using natural language queries.
Updated 10 months ago (2025-11-26 16:08 UTC)
-
RentCast MCP Server
Real Estate Search Open Data
robcerda
A
license
B
quality
D
maintenance
Connects Claude to the RentCast API to provide tools for accessing property valuations, rent estimates, and real estate market statistics. Users can retrieve detailed property data and active listings for specific ZIP codes through natural language queries.
Updated a year ago (2025-07-01 20:41 UTC)
12
1
MIT
nyc-property-intel
Government Data Real Estate Search
ccedacero
A
license
A
quality
A
maintenance
MCP server for NYC real estate due diligence. Lets Claude query 22+ NYC public-record databases — DOB/HPD/ECB violations, ACRIS deeds, DOF sales, 311 complaints, FDNY incidents, NYPD complaints, marshal evictions, PLUTO, rent stabilization — in plain English.
Updated 3 days ago (2026-09-12 01:05 UTC)
18
7
MIT
CRE Intelligence MCP
Finance Real Estate Research & Data
Zwondra
A
license
Not graded
quality
D
maintenance
Provides live commercial real estate data (rates, demographics) and analysis tools (DCF, rent roll parsing, lease abstraction, IC memo generation) within Claude Desktop.
Updated 3 months ago (2026-06-15 17:46 UTC)
1
MIT