Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

streeteasy_rentals_search

Search active StreetEasy rental listings by area, then filter by price, rooms, amenities, pets, transit, tours, and sort order. Use area IDs from /streeteasy/areas.

Instructions

Search StreetEasy rental listings. Searches active StreetEasy rentals in one or more areas with the public site's price, room, building, amenity, pet, open-house, tour, transit, and sort filters. Obtain valid area IDs from /streeteasy/areas.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based result page
sortNoResult order
amenityNoRequired amenity; repeat for multiple
area_idYesStreetEasy area ID from /streeteasy/areas; repeat for multiple areas
tour_3dNoRequire a 3D tour
max_sqftNoMaximum square footage
min_sqftNoMinimum square footage
per_pageNoResults per page, 1-500
max_priceNoMaximum monthly rent
min_priceNoMinimum monthly rent
open_houseNoRequire an open house within the next seven days
video_tourNoRequire a video tour
max_bedroomsNoMaximum bedrooms
min_bedroomsNoMinimum bedrooms; zero means studio
pets_allowedNoRequire listings that allow pets
transit_lineNoNearby transit line; repeat for multiple
building_typeNoBuilding type; repeat for multiple
max_bathroomsNoMaximum bathrooms
min_bathroomsNoMinimum bathrooms
optional_amenityNoPreferred amenity; results may omit these. Repeat for multiple.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.9

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that results are limited to 'active' listings and drawn from 'the public site's' filters, which is useful scoping context, but it says nothing about pagination behavior, result format, rate limits, or auth requirements despite a page/per_page surface.

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?

Two sentences, front-loaded with the core action and scope, with the area-ID dependency placed last. No filler, though the mid-sentence filter enumeration is somewhat listy and could be trimmed.

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 20-parameter search tool with no output schema and no annotations, the description covers scope, filter coverage, and the area_id dependency. It stops short of describing pagination semantics or what a result contains, leaving an agent to infer return shape from the schema alone.

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 schema already documents all 20 parameters, including required area_id and its provenance. The description's summary of filter families ('price, room, building, amenity, pet, open-house, tour, transit, and sort') maps onto the schema but adds no syntax or format detail beyond it, so baseline 3 applies.

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 gives a specific verb and resource ('Search StreetEasy rental listings') and scopes it to 'active StreetEasy rentals in one or more areas', then enumerates the filter categories (price, room, building, amenity, pet, open-house, tour, transit, sort). It implicitly distinguishes itself from streeteasy_sales_search via the 'rental' qualifier, but never names that sibling explicitly.

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 provides one concrete prerequisite: 'Obtain valid area IDs from /streeteasy/areas', which routes the agent to a sibling tool for setup. However, it gives no explicit when-to-use/when-not guidance relative to streeteasy_quick_search or streeteasy_sales_search, so usage is only implied.

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

Deploy Server

Other Tools