Building intelligence for NYC, LA, Chicago rentals: violations, 311, reviews, rents, landlords.
Full report card for one building: LucidIQ score and letter grade, HPD/DOB violation counts, 311 complaint total, top violation categories (pests, heat, leaks, ...), review count and average rating, rent summary by bedroom count, rent stabilization, landlord name with their record URL, and 2-3 similar nearby buildings. Requires the building's slug — call search_buildings first if you only have an address. The returned url has the complete timeline, all reviews, and rent history; share it with the user.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City/metro: "nyc", "los-angeles", or "chicago" | |
| slug | Yes | Building slug from search_buildings results, e.g. "48-04-48th-avenue" |
| Name | Required | Description |
|---|---|---|
| url | Yes | Canonical lucidrents.com page URL (UTM-tagged) |
| zip | No | |
| city | Yes | |
| more | Yes | What the linked page adds beyond this payload |
| slug | Yes | |
| grade | No | Letter grade derived from the score ("A+" through "F", "—" when unscored) |
| score | No | LucidIQ score, 0-100 |
| issues | Yes | |
| address | No | |
| borough | No | |
| reviews | Yes | |
| landlord | No | Owner/manager with their record URL, when on file |
| sections | Yes | Deep links to page sections |
| data_as_of | Yes | ISO date of the data snapshot |
| year_built | No | |
| total_units | No | |
| rent_summary | Yes | Rent summary by bedroom count |
| similar_nearby | Yes | |
| rent_stabilized | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent operation, so the description need not repeat that. It adds valuable context beyond annotations by listing the exact contents of the report and noting that 'the returned url has the complete timeline, all reviews, and rent history', which is behavioral info about the output.
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 a single, dense sentence front-loaded with the report contents, followed by a concise prerequisite note. It avoids extraneous words, though the enumerated list is somewhat long; still, every element contributes to the agent's understanding.
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?
Given the tool's complexity (report with many fields) and the presence of an output schema, the description effectively covers purpose, inputs, and output behavior, including the pointer to the full URL. It doesn't address error cases or rate limits, but those are not implied as critical for this read-only tool, so it is adequately complete.
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% for both parameters (city and slug), so baseline is 3. The description adds that slug comes from 'search_buildings results' and gives an example format, but it doesn't elaborate on the city parameter beyond the schema. This is a marginal enhancement that warrants a 3.
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 clearly states the tool produces a 'full report card for one building' enumerating specific data points (LucidIQ score, violation counts, rent summary). It uniquely identifies this as the comprehensive building report, distinguishing it from siblings like get_landlord_record or get_review_summary which focus on narrower aspects.
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 explicitly directs the agent to 'call search_buildings first if you only have an address,' establishing a clear prerequisite and linking to a sibling. While it doesn't explicitly state when not to use it, this guidance is sufficient context for proper invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public record for a landlord / property owner: portfolio size, total violations, 311 complaints, average building score across the portfolio, and worst building where available. Accepts either the owner name as it appears in a building report (e.g. "SMITH REALTY LLC") or a landlord page slug. The returned url lists every building they own with per-building records.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City/metro: "nyc", "los-angeles", or "chicago" | |
| slugOrName | Yes | Owner name or landlord slug. Building reports include the exact owner name. |
| Name | Required | Description |
|---|---|---|
| url | Yes | Canonical lucidrents.com page URL (UTM-tagged) |
| city | Yes | |
| more | Yes | What the linked page adds beyond this payload |
| name | Yes | |
| data_as_of | Yes | ISO date of the data snapshot |
| portfolio_size | Yes | Number of buildings on record |
| worst_building | No | |
| total_complaints | Yes | |
| total_violations | Yes | |
| avg_building_grade | No | Letter grade derived from the score ("A+" through "F", "—" when unscored) |
| avg_building_score | No | |
| total_dob_violations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive. The description adds useful context by stating the record is public, noting the 'worst building where available' caveat, and explaining that the returned URL lists all owned buildings with per-building records.
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 tight and front-loaded: it opens with the tool's purpose, lists the key data fields, then covers input forms and output behavior. Every sentence contributes meaningful information without repetition or fluff.
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 two-parameter read-only tool with a full output schema and strong annotations, the description is sufficiently complete. It covers purpose, inputs, example identifier, and output characteristics, leaving no major gaps for an agent to select and invoke 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 coverage is 100% and property descriptions already define the parameters. The description adds a concrete example ('SMITH REALTY LLC') and clarifies the owner name should appear exactly as it does in a building report, which supplements the schema's meaning for slugOrName.
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 clearly identifies the tool as fetching a public record for a landlord/property owner and enumerates the key data points: portfolio size, violations, 311 complaints, average building score, and worst building. This distinguishes it from sibling tools like get_building_report, which target individual buildings.
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 makes clear when this tool is appropriate: when you need landlord-level portfolio data rather than a single building report. It also specifies acceptable identifier forms (owner name or landlord page slug). It does not explicitly exclude alternative tools, 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.
Neighborhood snapshot for a zip code: median asking rents by bedroom count and a 12-month crime summary (violent / property / quality-of-life, with year-over-year totals) sourced from the local police department. Use this for "what does rent cost in " and "is safe" questions. The returned url is the neighborhood page with building listings and trend charts.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | 5-digit zip code, e.g. "11377" | |
| city | Yes | City/metro: "nyc", "los-angeles", or "chicago" |
| Name | Required | Description |
|---|---|---|
| url | Yes | Canonical lucidrents.com page URL (UTM-tagged) |
| zip | Yes | |
| city | Yes | |
| more | Yes | What the linked page adds beyond this payload |
| crime | No | 12-month crime summary from the local police department |
| data_as_of | Yes | ISO date of the data snapshot |
| neighborhood | No | Neighborhood name for the zip, when known |
| median_rents_by_bedrooms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful context beyond those annotations by mentioning the source, the time window, the specific metric categories, and the returned URL. It is transparent enough, though it could mention coverage limitations or city support explicitly.
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 three compact sentences: what is returned, when to use it, and what the returned URL offers. Every sentence earns its place and the structure is easy for an agent to consume.
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 read-only tool with rich annotations and an output schema, this description is remarkably complete: it names the data categories, source, cadence, typical user questions, and the return-link meaning. It does not clarify why the city parameter is required or which city values are supported, which creates minor ambiguity.
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?
The input schema covers both parameters with descriptions, so the baseline of 3 applies. The free-text description adds little semantic detail about the parameters themselves beyond referring to a zip code, and the city parameter's allowed values are left to the schema, which actually contains an enum/description mismatch.
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 clearly defines the tool as a neighborhood snapshot for a zip code, naming the exact contents: median asking rents by bedroom count and a 12-month crime summary. It is specific and easily distinguished from the sibling building, landlord, review, and search tools.
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 says to use the tool for 'what does rent cost in <area>' and 'is <area> safe' questions, which gives the agent clear when-to-use guidance. It does not explicitly list when-not-to-use or call out an alternative sibling, so it falls just 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.
Tenant review summary for one building: review count, average rating, 1-5 star distribution, and up to 3 recent pull quotes from published tenant reviews. Requires the building's slug — call search_buildings first if you only have an address. The returned url (anchored at #reviews) has every review in full text.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City/metro: "nyc", "los-angeles", or "chicago" | |
| slug | Yes | Building slug from search_buildings results, e.g. "48-04-48th-avenue" |
| Name | Required | Description |
|---|---|---|
| url | Yes | Canonical lucidrents.com page URL (UTM-tagged) |
| city | Yes | |
| more | Yes | What the linked page adds beyond this payload |
| slug | Yes | |
| address | No | |
| avg_rating | No | Average rating, 1-5 |
| data_as_of | Yes | ISO date of the data snapshot |
| pull_quotes | Yes | Up to 3 recent review excerpts |
| review_count | Yes | |
| building_grade | No | Letter grade derived from the score ("A+" through "F", "—" when unscored) |
| building_score | No | |
| rating_distribution | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful context by noting that only published tenant reviews are included, quotes are limited to 3, and the returned URL anchored at #reviews contains the full review text.
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 sentences with no filler. The first sentence front-loads the purpose and output contents; the second covers prerequisites and a key output detail.
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 read-only tool with rich annotations, full schema coverage, and an output schema, this description is complete. It covers the purpose, scope, prerequisite workflow, and a relevant output caveat without needing to restate structured metadata.
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?
Input schema description coverage is 100%, so the baseline is 3. The description adds the workflow of using search_buildings to obtain a slug, but it provides no additional meaning for the city parameter and does not resolve the schema's inconsistency where the enum lists only 'nyc' while the property description mentions multiple metros.
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 precisely what the tool does: provides a tenant review summary for one building, including review count, average rating, 1-5 star distribution, and up to 3 recent pull quotes. This clearly distinguishes it from sibling tools like get_landlord_record or get_neighborhood_stats.
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 explains that the building slug is required and directs the caller to search_buildings first if only an address is available. This is a clear prerequisite and usage alternative, helping the agent know exactly how to invoke the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search LucidRents for apartment buildings by address, building name, or partial address. Covers ~2M buildings in New York City, Los Angeles, and Chicago with public-record data: housing violations, 311 complaints, tenant reviews, rents, and building scores. Returns up to 10 matches with each building's slug (needed for get_building_report / get_review_summary) and its lucidrents.com report URL. Start here when the user gives an address.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional city filter. Omit to search all covered cities. | |
| query | Yes | Address or building name to search, e.g. "48-04 48th Ave" or "350 Park Ave" |
| Name | Required | Description |
|---|---|---|
| city | Yes | City searched, or "all" |
| more | Yes | What the linked page adds beyond this payload |
| query | Yes | |
| results | Yes | Up to 10 matches, best first |
| data_as_of | Yes | ISO date of the data snapshot |
| result_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior, so the description adds value by disclosing the match cap (10), city scope, data sources, and output components (slug + report URL). This goes beyond the structured metadata without contradicting it.
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 three sentences, front-loads the core purpose, and every sentence adds useful information: coverage, data types, return contents, and when to use. No wasted words or redundant restating 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?
Given the output schema exists and annotations cover safety, the description provides enough operational context: city coverage, public-record data categories, result limit, output purpose (slug for downstream tools), and a usage cue. This is complete for a read-only search 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?
Schema coverage is 100% and the schema already documents query and city with examples and constraints. The description reinforces that query can be an address or building name and that city is optional, but it doesn't add symbolic meaning beyond the schema. 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 clearly names the verb + resource ('Search LucidRents for apartment buildings') and specifies the search dimensions (address, building name, partial address). It also differentiates this from siblings by noting it produces the slug needed for downstream report tools.
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 says 'Start here when the user gives an address,' which is explicit when-to-use guidance. It also explains that the returned slug is needed for get_building_report / get_review_summary, establishing the tool's place in the workflow. It doesn't list explicit when-not-to-use scenarios, but the context is clear enough.
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. Dates show when Glama detected each change.
get_building_report1 field changedInput schema / properties / city / enumPrevious value: -[
- "nyc",
- "los-angeles",
- "chicago"
-]New value: +[
+ "nyc"
+]get_landlord_record1 field changedInput schema / properties / city / enumPrevious value: -[
- "nyc",
- "los-angeles",
- "chicago"
-]New value: +[
+ "nyc"
+]get_neighborhood_stats1 field changedInput schema / properties / city / enumPrevious value: -[
- "nyc",
- "los-angeles",
- "chicago"
-]New value: +[
+ "nyc"
+]get_review_summary1 field changedInput schema / properties / city / enumPrevious value: -[
- "nyc",
- "los-angeles",
- "chicago"
-]New value: +[
+ "nyc"
+]search_buildings1 field changedInput schema / properties / city / enumPrevious value: -[
- "nyc",
- "los-angeles",
- "chicago"
-]New value: +[
+ "nyc"
+]get_building_report1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "address": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "borough": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "city": {
+ "type": "string"
+ },
+ "data_as_of": {
+ "description": "ISO date of the data snapshot",
+ "type": "string"
+ },
+ "grade": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Letter grade derived from the score (\"A+\" through \"F\", \"—\" when unscored)"
+ },
+ "issues": {
+ "additionalProperties": {},
+ "properties": {
+ "complaints_311": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "dob_violations": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "evictions_filed": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "hpd_violations": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "litigations": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "top_violation_categories": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "count": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "category",
+ "count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "top_violation_categories"
+ ],
+ "type": "object"
+ },
+ "landlord": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "url": {
+ "description": "Canonical lucidrents.com page URL (UTM-tagged)",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "url"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Owner/manager with their record URL, when on file"
+ },
+ "more": {
+ "description": "What the linked page adds beyond this payload",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "rent_stabilized": {
+ "additionalProperties": {},
+ "properties": {
+ "stabilized": {
+ "type": "boolean"
+ },
+ "stabilized_units": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "stabilized"
+ ],
+ "type": "object"
+ },
+ "rent_summary": {
+ "description": "Rent summary by bedroom count",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "bedrooms": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "listing_count": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "max_rent": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "median_rent": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "min_rent": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "source": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "reviews": {
+ "additionalProperties": {},
+ "properties": {
+ "avg_rating": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "count": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "score": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "LucidIQ score, 0-100"
+ },
+ "sections": {
+ "additionalProperties": {},
+ "description": "Deep links to page sections",
+ "properties": {
+ "landlord": {
+ "type": "string"
+ },
+ "rent_intelligence": {
+ "type": "string"
+ },
+ "reviews": {
+ "type": "string"
+ },
+ "violations": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "violations",
+ "reviews",
+ "rent_intelligence",
+ "landlord"
+ ],
+ "type": "object"
+ },
+ "similar_nearby": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "address": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "grade": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Letter grade derived from the score (\"A+\" through \"F\", \"—\" when unscored)"
+ },
+ "score": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "slug": {
+ "type": "string"
+ },
+ "total_units": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "url": {
+ "description": "Canonical lucidrents.com page URL (UTM-tagged)",
+ "type": "string"
+ },
+ "year_built": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "slug",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "total_units": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "url": {
+ "description": "Canonical lucidrents.com page URL (UTM-tagged)",
+ "type": "string"
+ },
+ "year_built": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "zip": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "city",
+ "slug",
+ "rent_stabilized",
+ "issues",
+ "reviews",
+ "rent_summary",
+ "similar_nearby",
+ "url",
+ "sections",
+ "data_as_of",
+ "more"
+ ],
+ "type": "object"
+}get_landlord_record1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "avg_building_grade": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Letter grade derived from the score (\"A+\" through \"F\", \"—\" when unscored)"
+ },
+ "avg_building_score": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "city": {
+ "type": "string"
+ },
+ "data_as_of": {
+ "description": "ISO date of the data snapshot",
+ "type": "string"
+ },
+ "more": {
+ "description": "What the linked page adds beyond this payload",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "name": {
+ "type": "string"
+ },
+ "portfolio_size": {
+ "description": "Number of buildings on record",
+ "type": "number"
+ },
+ "total_complaints": {
+ "type": "number"
+ },
+ "total_dob_violations": {
+ "type": "number"
+ },
+ "total_violations": {
+ "type": "number"
+ },
+ "url": {
+ "description": "Canonical lucidrents.com page URL (UTM-tagged)",
+ "type": "string"
+ },
+ "worst_building": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {
+ "address": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "violations": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "name",
+ "city",
+ "portfolio_size",
+ "total_violations",
+ "total_dob_violations",
+ "total_complaints",
+ "url",
+ "data_as_of",
+ "more"
+ ],
+ "type": "object"
+}get_neighborhood_stats1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "city": {
+ "type": "string"
+ },
+ "crime": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {
+ "property": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "quality_of_life": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "violent": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "12-month crime summary from the local police department"
+ },
+ "data_as_of": {
+ "description": "ISO date of the data snapshot",
+ "type": "string"
+ },
+ "median_rents_by_bedrooms": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "bedrooms": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "median_rent": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "more": {
+ "description": "What the linked page adds beyond this payload",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "neighborhood": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Neighborhood name for the zip, when known"
+ },
+ "url": {
+ "description": "Canonical lucidrents.com page URL (UTM-tagged)",
+ "type": "string"
+ },
+ "zip": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "city",
+ "zip",
+ "median_rents_by_bedrooms",
+ "url",
+ "data_as_of",
+ "more"
+ ],
+ "type": "object"
+}get_review_summary1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "address": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "avg_rating": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Average rating, 1-5"
+ },
+ "building_grade": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Letter grade derived from the score (\"A+\" through \"F\", \"—\" when unscored)"
+ },
+ "building_score": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "city": {
+ "type": "string"
+ },
+ "data_as_of": {
+ "description": "ISO date of the data snapshot",
+ "type": "string"
+ },
+ "more": {
+ "description": "What the linked page adds beyond this payload",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "pull_quotes": {
+ "description": "Up to 3 recent review excerpts",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "date": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "excerpt": {
+ "type": "string"
+ },
+ "rating": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "excerpt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "rating_distribution": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "stars": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "stars",
+ "count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "review_count": {
+ "type": "number"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "url": {
+ "description": "Canonical lucidrents.com page URL (UTM-tagged)",
+ "type": "string"
+ }
+ },
+ "required": [
+ "city",
+ "slug",
+ "review_count",
+ "rating_distribution",
+ "pull_quotes",
+ "url",
+ "data_as_of",
+ "more"
+ ],
+ "type": "object"
+}search_buildings1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "city": {
+ "description": "City searched, or \"all\"",
+ "type": "string"
+ },
+ "data_as_of": {
+ "description": "ISO date of the data snapshot",
+ "type": "string"
+ },
+ "more": {
+ "description": "What the linked page adds beyond this payload",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "query": {
+ "type": "string"
+ },
+ "result_count": {
+ "type": "number"
+ },
+ "results": {
+ "description": "Up to 10 matches, best first",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "address": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "borough": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "city": {
+ "type": "string"
+ },
+ "grade": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Letter grade derived from the score (\"A+\" through \"F\", \"—\" when unscored)"
+ },
+ "review_count": {
+ "type": "number"
+ },
+ "score": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "LucidIQ score, 0-100"
+ },
+ "slug": {
+ "description": "Building slug — pass to get_building_report / get_review_summary",
+ "type": "string"
+ },
+ "url": {
+ "description": "Canonical lucidrents.com page URL (UTM-tagged)",
+ "type": "string"
+ },
+ "violation_count": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "slug",
+ "city",
+ "violation_count",
+ "review_count",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "query",
+ "city",
+ "result_count",
+ "results",
+ "data_as_of",
+ "more"
+ ],
+ "type": "object"
+}get_building_reportget_landlord_recordget_neighborhood_statsget_review_summarysearch_buildingsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Search NYC rentals and sales, property details, building data, and market analytics
Agent-ready NYC public records. Hosted, source-backed civic data organized around durable anchors.
U.S. real-estate data: property records, AVM value + rent estimates, sale/rental listings.
Property intelligence: 180M+ US parcels — lookup, search, owners, hazards, permits, deeds.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource: search, building report, landlord record, neighborhood stats, and review summary. There is no overlap in purpose, and descriptions make it clear when to use each.
All tools follow a consistent `verb_noun` pattern using snake_case (search_buildings, get_building_report, get_landlord_record, get_neighborhood_stats, get_review_summary). This makes the API predictable and easy to navigate.
With 5 tools, the set is well-scoped for a building intelligence server. It covers search, detailed reports, landlord info, and neighborhood context without bloat.
The tool surface covers the core lifecycle of a user's query: search, building details (including violations, rent, and similar buildings), landlord records, neighborhood stats, and reviews. No essential operation is missing for the stated purpose.