Public records for any NYC property by address or BBL: permits, violations, sales, owners.
Scored across 5 tools
The five tools mostly target distinct tasks: identifier-based fact retrieval, address resolution, street/ZIP search, sales history, and open issues. The only meaningful overlap is between get_property and lookup_property, but the descriptions clearly distinguish known-BBL/BIN usage from free-text address lookup.
All tools use snake_case with a verb-first pattern: get_, list_, lookup_, and search_. The mix of get_property and lookup_property introduces mild synonym variation, but the convention remains predictable and readable.
Five tools is well scoped for a focused NYC property-facts server. Each tool has a clear role, and there is no obvious filler.
The surface covers the main read-only lifecycle: resolve address, fetch by BBL/BIN, search streets/ZIPs, view sales history, and inspect open issues. Minor gaps may exist for deeper standalone property attributes or broader related datasets, but core workflows are covered.
Return the full fact sheet for a tax lot by 10-digit BBL (borough-block-lot, e.g. 3030090016) or by 7-digit DOB building number (BIN). Requires "bbl" or "bin" (if both are sent, bbl is used).
| Name | Required | Description | Default |
|---|---|---|---|
| bbl | No | 10-digit BBL (borough-block-lot), e.g. "3030090016". Send it as text. Required unless "bin" is given. | |
| bin | No | 7-digit DOB building number (BIN), e.g. "3070696". Send it as text. Required unless "bbl" is given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile: readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds the bbl/bin precedence rule, but it does not describe return format, error behavior, or any other behavioral traits beyond what the annotations and schema already provide.
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?
The description is two tight sentences with no wasted language. The primary purpose and identifier requirement are front-loaded, and the precedence rule follows naturally.
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 simple two-parameter read-only lookup, the description plus annotations and fully covered schema give enough information to invoke it correctly. The remaining minor gap is that it does not clarify the relationship to lookup_property or specify what the 'full fact sheet' contains.
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%, so the baseline is 3, and the schema already explains both parameters and their formats. The description adds meaningful information beyond the schema by stating the precedence rule: if both bbl and bin are sent, bbl is used.
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 states a specific verb and resource: return the full fact sheet for a tax lot, identified by BBL or BIN. It is clear what the tool does, but it does not explicitly distinguish itself from the sibling lookup_property tool.
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?
The description gives the input condition that either bbl or bin is required and that bbl wins if both are sent. However, it does not explain when to use this tool instead of siblings such as lookup_property or search_properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deeds recorded with the NYC City Register (ACRIS) for a property: date, stated price (0 = non-market transfer), grantors, grantees, and whether the deed covers several lots. Requires one of "address", "bbl" or "bin".
| Name | Required | Description | Default |
|---|---|---|---|
| bbl | No | 10-digit BBL (borough-block-lot), e.g. "3030090016". Send it as text. | |
| bin | No | 7-digit DOB building number (BIN), e.g. "3070696". Send it as text. | |
| zip | No | Optional 5-digit ZIP, sent as text | |
| limit | No | Maximum deeds returned | |
| address | No | NYC street address, e.g. "98 Grattan St, Brooklyn". Units (Apt 3B), borough and ZIP are optional; a 10-digit BBL or 7-digit BIN also works. | |
| borough | No | Optional: Manhattan, Bronx, Brooklyn, Queens or Staten Island |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered. The description adds genuine domain behavior the annotations cannot: the data source (ACRIS), the meaning of price = 0 (non-market transfer), and the multi-lot deed flag. It stops short of disclosing ordering, pagination, or what an empty result means.
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: the first front-loads what is returned, the second front-loads the input constraint. No filler, no restatement of the title.
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 usefully compensates by listing returned fields, and it covers the key input constraint for a 6-parameter tool. Gaps remain around result ordering, the 25/200 limit behavior, and how deduplication across multiple lots works.
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 100%, so baseline is 3; the description earns an extra point by stating the at-least-one-of address/bbl/bin constraint, which the schema's empty required array does not express. It does not add format or interaction detail for limit, zip, or borough beyond the schema.
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+resource (deeds recorded with NYC ACRIS for a property) and enumerates the returned fields (date, price, grantors, grantees, multi-lot flag), which clearly separates it from the sibling property-lookup tools. An agent can identify the resource and result shape from the first clause alone.
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?
The 'Requires one of address, bbl or bin' sentence gives the agent an input-selection rule, but there is no explicit when-to-use guidance, no mention of when to prefer get_property or search_properties instead, and no exclusions. Usage is only implicitly conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every open item for a property: DOB jobs with a permit issued but no sign-off, active DOB and ECB violations, open HPD violations, and OATH tickets with an unpaid balance or a pending hearing. Each record has status, dates, a plain-English description and its source dataset. Requires one of "address", "bbl" or "bin".
| Name | Required | Description | Default |
|---|---|---|---|
| bbl | No | 10-digit BBL (borough-block-lot), e.g. "3030090016". Send it as text. | |
| bin | No | 7-digit DOB building number (BIN), e.g. "3070696". Send it as text. | |
| zip | No | Optional 5-digit ZIP, sent as text | |
| limit | No | Maximum records per section | |
| address | No | NYC street address, e.g. "98 Grattan St, Brooklyn". Units (Apt 3B), borough and ZIP are optional; a 10-digit BBL or 7-digit BIN also works. | |
| borough | No | Optional: Manhattan, Bronx, Brooklyn, Queens or Staten Island |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered; the description adds genuinely new behavioral detail by defining the 'open' predicate for each dataset and describing the shape of each returned record (status, dates, plain-English description, source dataset). It stops short of noting result volume, section-level paging behavior, or how conflicting identifiers are resolved.
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 sentences, zero filler. The scope and category enumeration come first, and the hard input requirement is placed last as a gate, which is exactly where an agent needs it before constructing a 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?
For a six-parameter read-only aggregation tool with annotations and no output schema, the description covers the necessary ground: what counts as open, what a record contains, and the identifier requirement. The remaining gaps (whether multiple identifiers are ANDed, how the per-section limit affects total results) are minor but not fully closed by the schema.
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 100%, so the baseline is 3, but the description adds a constraint the schema does not express: although the schema marks zero parameters required, the prose states that one of address, bbl or bin must be supplied. That is real meaning beyond the structured fields, though it does not clarify precedence when several identifiers are sent or what zip/borough/limit do in combination.
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?
Uses a specific verb ('List') plus a precisely scoped resource ('every open item for a property') and then enumerates the exact categories returned: DOB jobs without sign-off, active DOB/ECB and HPD violations, and OATH tickets unpaid or pending hearing. That level of enumeration makes it unmistakable against siblings like get_property or search_properties, which do not aggregate open compliance items.
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?
The closing sentence establishes the entry condition ('Requires one of "address", "bbl" or "bin"'), and the definition of 'open' is spelled out per category, so an agent knows exactly which situation this tool serves. It does not name an alternative tool or state when to prefer get_property over this, which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a free-text NYC address to its tax lot (BBL) and return the property facts: summary, owner of record, building, assessment, last priced deed and open-item counts. Returns the best match with a 0-1 confidence, a plain-English confidence_explanation, a machine-readable match_type, the HTML/Markdown/JSON URLs and up to 4 alternatives. Requires "address". Use get_property for a known BBL/BIN.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | Optional 5-digit ZIP, sent as text | |
| address | Yes | NYC street address, e.g. "98 Grattan St, Brooklyn". Units (Apt 3B), borough and ZIP are optional; a 10-digit BBL or 7-digit BIN also works. | |
| borough | No | Optional: Manhattan, Bronx, Brooklyn, Queens or Staten Island |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds useful return behavior: best match with 0-1 confidence, confidence_explanation, match_type, HTML/Markdown/JSON URLs, and up to 4 alternatives. It does not explicitly state no-match behavior, but the behavioral disclosure is otherwise strong.
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?
The description is front-loaded with the core resolution behavior and return summary, then immediately gives the sibling alternative. Both sentences carry useful information with no wasted wording.
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 carries the burden of explaining what comes back, and it does so: property facts, confidence, explanation, match type, URLs, and alternatives. Combined with full schema coverage and clear annotations, an agent has enough context to call the tool correctly.
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%, so the schema already documents address, zip, and borough. The description repeats that address is required but adds no additional parameter semantics beyond what the schema provides, making the baseline score appropriate.
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 uses a specific verb and resource: resolve a free-text NYC address to its tax lot (BBL) and return property facts. It clearly distinguishes this from get_property, which is for a known BBL/BIN, so an agent can select it without opening the schema.
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 explicitly states the required input (address) and names the alternative for known identifiers: 'Use get_property for a known BBL/BIN.' This gives a clear when-to-use condition and an explicit when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tax lots on a street (prefix match, e.g. "Grattan St") and/or in a ZIP code, with address, building class, units, owner of record and open-item count. Requires "street" and/or "zip"; borough and house_number only narrow the search. Paginate with limit/offset; total is the number of matches.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | 5-digit ZIP, sent as text. Required unless "street" is given. | |
| limit | No | ||
| offset | No | ||
| street | No | Street name, e.g. "Grattan St" or "5th Ave". Required unless "zip" is given. | |
| borough | No | Optional borough name | |
| house_number | No | Optional house number, sent as text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and closed-world, and the description adds real behavioral context on top: prefix-match semantics for street, pagination via limit/offset, and the meaning of the 'total' field. It doesn't discuss empty-result or error behavior, keeping it below a 5.
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 dense sentences with zero filler: the first front-loads what is returned and how matching works, the second covers requirements and pagination. Every clause carries information an agent needs.
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?
There is no output schema, but the description compensates by enumerating the returned fields (address, building class, units, owner of record, open-item count) and explaining the total count. Requirements, narrowing behavior, and pagination are all covered, so nothing critical is missing for a 6-parameter read tool.
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?
With 67% schema coverage, the schema already documents the street/zip requirement rule and both examples. The description's genuinely additive piece is 'prefix match' for street and the narrowing semantics of borough/house_number; limit and offset are restated rather than explained (no max or default mentioned). Baseline-plus for the prefix detail, but not rich parameter guidance.
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 and resource ('List tax lots') plus the scoping dimensions (street and/or ZIP) and even previews the returned fields. It is clear what the tool does, though it never differentiates itself from sibling lookup_property or get_property, which an agent must infer from the list-vs-single distinction.
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?
Explicitly gives the selection constraint: 'Requires "street" and/or "zip"; borough and house_number only narrow the search,' which tells the agent exactly which parameters are mandatory vs refining. It stops short of naming an alternative tool for single-lot lookups, so no exclusions are stated.
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.
get_property2 fields changedInput schema / properties / bbl / descriptionPrevious value: -"10-digit BBL, e.g. 3030090016"New value: +"10-digit BBL (borough-block-lot), e.g. \"3030090016\". Send it as text. Required unless \"bin\" is given."Input schema / properties / bin / descriptionPrevious value: -"7-digit BIN"New value: +"7-digit DOB building number (BIN), e.g. \"3070696\". Send it as text. Required unless \"bbl\" is given."get_sales_history5 fields changedInput schema / properties / bbl / descriptionPrevious value: -"10-digit BBL (instead of address)"New value: +"10-digit BBL (borough-block-lot), e.g. \"3030090016\". Send it as text."Input schema / properties / binAdded value: +{
+ "description": "7-digit DOB building number (BIN), e.g. \"3070696\". Send it as text.",
+ "type": "string"
+}Input schema / properties / boroughAdded value: +{
+ "description": "Optional: Manhattan, Bronx, Brooklyn, Queens or Staten Island",
+ "type": "string"
+}Input schema / properties / limit / descriptionAdded value: +"Maximum deeds returned"Input schema / properties / zipAdded value: +{
+ "description": "Optional 5-digit ZIP, sent as text",
+ "type": "string"
+}list_open_issues5 fields changedInput schema / properties / bbl / descriptionPrevious value: -"10-digit BBL (instead of address)"New value: +"10-digit BBL (borough-block-lot), e.g. \"3030090016\". Send it as text."Input schema / properties / binAdded value: +{
+ "description": "7-digit DOB building number (BIN), e.g. \"3070696\". Send it as text.",
+ "type": "string"
+}Input schema / properties / boroughAdded value: +{
+ "description": "Optional: Manhattan, Bronx, Brooklyn, Queens or Staten Island",
+ "type": "string"
+}Input schema / properties / limit / descriptionAdded value: +"Maximum records per section"Input schema / properties / zipAdded value: +{
+ "description": "Optional 5-digit ZIP, sent as text",
+ "type": "string"
+}lookup_property1 field changedInput schema / properties / zip / descriptionPrevious value: -"Optional 5-digit ZIP"New value: +"Optional 5-digit ZIP, sent as text"search_properties3 fields changedInput schema / properties / house_number / descriptionAdded value: +"Optional house number, sent as text"Input schema / properties / street / descriptionPrevious value: -"Street name, e.g. \"Grattan St\" or \"5th Ave\""New value: +"Street name, e.g. \"Grattan St\" or \"5th Ave\". Required unless \"zip\" is given."Input schema / properties / zip / descriptionPrevious value: -"5-digit ZIP"New value: +"5-digit ZIP, sent as text. Required unless \"street\" is given."get_propertyget_sales_historylist_open_issueslookup_propertysearch_propertiesNYC and US property records: owners, LLC officers, mortgages, pre-foreclosures and investors.
Agent-ready NYC public records. Hosted, source-backed civic data organized around durable anchors.
Building intelligence for NYC, LA, Chicago rentals: violations, 311, reviews, rents, landlords.
Search NYC rentals and sales, property details, building data, and market analytics
Add one secure layer between your agents and this server.
