Live NYC apartments with tenant reviews and public records for every building and landlord.
Scored across 5 tools
Each tool targets a distinct entity/action: entity reports for buildings vs landlords, single-apartment lookup, live search, and alternatives. The only mild overlap is between search_apartments and nearby_apartments, since both surface listings, though the descriptions make the 'similar to this unit' filter distinguishable.
Names mix conventions: noun_report (building_report, landlord_report), verb_noun (get_apartment, search_apartments), and adjective_noun (nearby_apartments). The names are still readable and none are ambiguous, but there is no single predictable pattern an agent can rely on.
Five tools is a tight, well-scoped surface for a rental-research server, and each one earns its place: two entity reports, one detail lookup, one search, and one alternatives finder. Nothing feels redundant or padded.
The read-only research lifecycle is largely covered: discover listings, inspect units, evaluate buildings and landlords, and find alternatives. Minor gaps exist around area/neighborhood-driven browsing and bulk listing retrieval (e.g., all units in a building or by a landlord are only summaries inside the report tools).
What a NYC building is like: tenant rating and review summary, open HPD violations, evictions, housing-court cases, bedbug reports, rent stabilization, who owns and manages it, and apartments for rent there. Pass a building id, an openigloo.com link, or a NYC street address.
| Name | Required | Description | Default |
|---|---|---|---|
| building | Yes | Building id, openigloo.com/building/... or /unit/... link, or a street address such as '221 West 105th Street, Manhattan' |
| Name | Required | Description |
|---|---|---|
| faqs | Yes | |
| about | Yes | |
| units | Yes | |
| floors | Yes | |
| owners | Yes | |
| ratings | Yes | |
| building | Yes | |
| apartments | Yes | |
| year_built | Yes | |
| reviews_url | Yes | The building page, where renters read every review |
| neighborhood | Yes | |
| pet_friendly | Yes | |
| public_records | Yes | |
| review_summary | Yes | AI summary of the building's tenant reviews |
| rent_stabilized | Yes | |
| review_excerpts | Yes | |
| apartments_for_rent | Yes | |
| good_cause_eviction | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description's content list adds some sense of breadth and cost of the call, but says nothing about failure modes (ambiguous street address), result volume, or whether missing data is omitted versus null.
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, front-loaded with the payload and followed by input forms. The long enumeration of report sections is dense but each item is meaningful scoping information. Minor waste in the phrase 'What a NYC building is like', which is less informative than the list that follows it.
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?
An output schema exists, so return values need not be explained, and the description still usefully previews the report's coverage. For a single-parameter, read-only aggregator this is largely sufficient. What is absent is guidance on how an ambiguous or partial street address is resolved, the one realistic input pitfall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is a single parameter, so the schema already defines the accepted forms (id, openigloo link, street address). The description's 'Pass a building id, an openigloo.com link, or a NYC street address' largely restates that, adding no syntax, format, or ambiguity-resolution detail. Baseline 3 is 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 names the resource (a NYC building) and enumerates precisely what the report contains: tenant ratings, HPD violations, evictions, housing-court cases, bedbug reports, rent stabilization, ownership/management, and available rentals. That is far more specific than the title. It does not explicitly distinguish itself from siblings like landlord_report or get_apartment, which is why 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer you call this when you want a full building dossier rather than a unit (get_apartment) or an owner (landlord_report). There is no explicit when-to-use/when-not-to-use statement and no sibling is named. The input guidance ('Pass a building id, an openigloo.com link, or a NYC street address') is parameter help, not usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Details of one apartment on Openigloo: whether it is still for rent, rent, move-in date, lease length, description and photos. Pass an apartment id from a search result or an openigloo.com/unit link.
| Name | Required | Description | Default |
|---|---|---|---|
| apartment | Yes | Apartment id or openigloo.com/unit/... link |
| Name | Required | Description |
|---|---|---|
| apartment | Yes | |
| photo_urls | Yes | |
| description | Yes | |
| building_url | Yes | |
| lease_term_months | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a little useful context by framing this as a freshness check ('whether it is still for rent'), implying availability can change, but says nothing about what happens for a delisted or unknown id, nor about auth or rate limits.
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, front-loaded with the resource and the returned attributes, followed by the input-provenance hint. Nothing is filler.
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 an output schema, full parameter coverage, and read-only annotations, the description covers what an agent needs to select and call the tool. It is slightly short on edge-case behavior (invalid or delisted ids), but nothing essential is missing for a one-parameter lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is fully documented as 'Apartment id or openigloo.com/unit/... link'. The description only restates this and adds the minor hint that the id typically comes from a search result, which is marginal value over 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: 'Details of one apartment on Openigloo', then enumerates the fields exposed (availability, rent, move-in date, lease length, description, photos). The singular 'one apartment' implicitly separates it from search_apartments and nearby_apartments, though no sibling is named explicitly.
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?
'Pass an apartment id from a search result or an openigloo.com/unit link' gives clear workflow context: this is a follow-up call after a search or from an external link. No explicit exclusions or named alternatives are given, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a NYC landlord or management company is like: tenant ratings across its buildings, review summary, violations, evictions and housing-court cases, its buildings and apartments for rent. Pass a landlord id from building_report or an openigloo.com/contact link.
| Name | Required | Description | Default |
|---|---|---|---|
| landlord | Yes | Landlord id from building_report, or openigloo.com/contact link |
| Name | Required | Description |
|---|---|---|
| units | Yes | |
| ratings | Yes | |
| landlord | Yes | |
| buildings | Yes | |
| apartments | Yes | |
| is_individual | Yes | |
| top_buildings | Yes | |
| public_records | Yes | |
| review_summary | Yes | |
| review_excerpts | Yes | |
| apartments_for_rent | Yes | |
| on_worst_landlords_list_year | Yes | Latest year on the NYC Public Advocate's list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds the report's data coverage, but much of that overlaps with the output schema and it does not mention pagination, freshness, or permission details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence leads with what the report covers, then closes with the required input provenance. It is dense but has no filler or redundant explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only report with an output schema and rich annotations, the description covers purpose, data scope, and input source. It could better distinguish the sibling building_report, but nothing critical for calling the tool is missing.
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's landlord field already explains the id or contact-link source. The description repeats that meaning without adding format, validation, or resolution behavior, so 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 names a specific resource, a NYC landlord or management company, and enumerates the report's subject matter: tenant ratings, reviews, violations, evictions, court cases, buildings, and rentals. It does not explicitly contrast itself with building_report, but the landlord-level scope is clear from the opening phrase.
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 identifies valid input sources, a landlord id from building_report or an openigloo.com/contact link, which helps the agent invoke it. However, it does not state when to choose landlord_report over building_report or other apartment tools, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live alternatives near an apartment: similar rent and size in the same area. Use it when an apartment is rented or the renter wants more options. Pass an apartment id or openigloo.com/unit link.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| apartment | Yes | Apartment id or openigloo.com/unit/... link |
| Name | Required | Description |
|---|---|---|
| apartment | Yes | |
| alternatives | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add substance. It does, by defining what 'similar' means (rent, size, same area) and that results are live listings rather than historical. It omits ordering of results and that the result count is capped by the limit parameter.
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?
Three short sentences, front-loaded with the purpose, then usage, then input format. No redundant or filler wording; every sentence 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?
A simple two-parameter read tool with an output schema, so return values need no explanation. Purpose, trigger, and input format are all present; only the behavior of limit and result ordering are unaddressed.
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 50%: apartment is documented in the schema and the description restates the same accepted formats rather than adding new meaning, while limit has no description anywhere beyond its numeric bounds. Partial compensation for the gap, so a 3 is 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?
States a specific resource and scope: 'Live alternatives near an apartment: similar rent and size in the same area.' An agent can distinguish it from search_apartments because it is anchored to one apartment and constrained by similarity criteria, though no sibling is named explicitly.
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?
Gives concrete triggering conditions: 'when an apartment is rented or the renter wants more options.' Clear context for use, but it never states when to prefer search_apartments or building_report instead, so the routing choice is left partly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find apartments for rent right now in New York City. Returns live listings with rent, bedrooms, move-in date, the building's tenant rating and a link to each apartment on Openigloo.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | A NYC neighborhood or borough, e.g. 'Astoria', 'Upper West Side', 'Brooklyn'. Leave out for all of NYC. | |
| limit | No | How many apartments to return | |
| no_fee | No | Only apartments with no broker fee | |
| bedrooms | No | Bedroom counts to include: 0 = studio, 4 = four or more. E.g. [1, 2] | |
| max_rent | No | Highest monthly rent in US dollars | |
| min_rent | No | Lowest monthly rent in US dollars | |
| amenities | No | Required amenities | |
| move_in_by | No | Latest move-in date, YYYY-MM-DD | |
| pets_allowed | No | Only apartments that allow pets | |
| min_bathrooms | No | Fewest bathrooms | |
| building_history | No | Require a clean building record: tenant rating of 4+, no open violations, no evictions, no bedbugs in the last year | |
| rent_stabilized_only | No | Only rent-stabilized buildings |
| Name | Required | Description |
|---|---|---|
| note | No | |
| shown | Yes | |
| apartments | Yes | |
| search_url | Yes | Openigloo's apartment search, for more results and filters |
| total_matches | Yes | |
| areas_searched | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds that listings are 'live' and enumerates return fields, but since a rich output schema exists, that enumeration is largely redundant; nothing is said about result ordering, empty-result behavior, or result caps beyond the schema's limit.
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, front-loaded with the core action and scope, followed by the payoff. 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?
For a 12-parameter, all-optional search tool with full schema coverage, annotations, and an output schema, the description covers what the tool does and what comes back. A minor gap remains around result limits/defaults and how to chain into the sibling report tools, which the schema does not answer.
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%, with per-parameter descriptions for area, bedrooms encoding (0=studio, 4=four or more), rent bounds, and filter flags. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find apartments for rent') with an explicit scope ('New York City', 'right now'). It is clearly distinguishable from siblings like get_apartment (single listing), nearby_apartments (proximity), and the report tools. An agent can tell this is the primary discovery/search entry point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb 'Find' and the 'right now' live-listings framing, but the description never says when to prefer this over nearby_apartments, nor does it state that callers should follow up with get_apartment for a single listing or building_report for history. No exclusions or prerequisites are given.
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.
search_apartments1 field changedInput schema / $defs / BuildingRecord / descriptionPrevious value: -"Building-history filters, the data other rental sites don't have."New value: +"Building-history filters from tenant ratings and NYC public records."building_reportget_apartmentlandlord_reportnearby_apartmentssearch_apartmentsBuilding intelligence for NYC, LA, Chicago rentals: violations, 311, reviews, rents, landlords.
Search NYC rentals and sales, property details, building data, and market analytics
Find NYC rental apartments by budget, neighborhood, commute and amenities, with deal scores.
NYC rent data and guides; OAuth tools for apartment alerts, saved searches and lottery status.
Add one secure layer between your agents and this server.
