What can you do with this server?

This server provides an MCP interface to the StreetEasy GraphQL API, enabling LLM agents to search and retrieve NYC rental listings. * search_rentals: Search active NYC rentals filtered by area (name or numeric code), price range, bedrooms, bathrooms, amenities (e.g. WASHER_DRYER, DOORMAN, GYM), no-fee, and pet-friendly options. Supports sorting and pagination (up to 100/page). Returns compact summaries with listing IDs, photos, and URLs. * get_rental_details: Retrieve full details for a single listing by ID, including description, amenities, pricing history, building info, nearby transit/schools, and media (photos, floor plans, YouTube/Vimeo videos, 3D tours). * list_areas: Look up StreetEasy area names and numeric codes, with optional substring filtering (e.g. 'brooklyn', 'harlem'). * list_amenities: List all valid amenity enum tokens accepted by search_rentals. Notable limitations: Contact info and tour scheduling are not supported (users follow the listing URL directly). Cloud/datacenter deployments may require a residential proxy to bypass StreetEasy's bot-detection.

How do I use streeteasy-mcp?

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., "@streeteasy-mcp Search for 2-bedroom apartments in Brooklyn under $3000" 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.

streeteasy-mcp

by Alec2435

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

streeteasy-mcp

A remote MCP server that wraps the StreetEasy GraphQL API so an LLM agent can search and parse NYC rental listings.

It vendors the streeteasy-api client (v0.4.0) and exposes it over either stdio (local) or Streamable HTTP (remote) transport, so it can be connected to by Claude or any MCP client.

IMPORTANT

StreetEasy blocks datacenter/cloud IPs. Its API sits behind PerimeterX bot-detection that 403s cloud/datacenter IPs (AWS, GCP, Railway, etc.). The HTTP build deploys fine and the MCP layer works, but the upstream search_rentals / get_rental_details calls fail from a datacenter unless you do one of:

Run the stdio server locally from a normal home connection — see Run as a local MCP server, or
Route upstream calls through a residential proxy by setting STREETEASY_PROXY — this is what lets the hosted HTTP build (Railway, etc.) reach the API. See Proxy / bot-detection.

Tools

Tool	Description
`search_rentals`	Search active NYC rentals by area, price, beds, baths, amenities, pets. Returns compact listings + `totalCount`, paginated. Each listing includes `leadPhotoUrl` / `photoUrls` and a listing `url`.
`get_rental_details`	Full detail for one listing id: description, amenities, pricing history, building info, nearby transit/schools, and resolved media — `media.photoUrls`, `media.floorPlanUrls`, `media.videoLinks` (YouTube/Vimeo), `media.tour3dUrl`.
`list_areas`	Look up StreetEasy area names ↔ numeric codes (optionally filtered by a search term).
`list_amenities`	List the valid amenity enum tokens.

search_rentals accepts area names ("MANHATTAN", "Williamsburg", "upper east side") or numeric codes, and validates amenity tokens against the known set.

Media

Photos resolve to Zillow's CDN (photos.zillowstatic.com/fp/{key}-se_large_800_400.jpg), videos to their provider watch URL (YouTube/Vimeo) plus a thumbnail, and 3D tours to a direct tour3dUrl. All are public — no auth required.

Not included: contact info & inquiries

Listing agent contact details and "request a tour" inquiries are not exposed. They live behind StreetEasy's contact flow, which is protected by PerimeterX bot-detection (a "Press & Hold" human check). Automating it would mean evading bot-detection, so it's intentionally left out — the right pattern is to surface the listing url and let a human submit the tour request in their browser.

Related MCP server: Apartment Hunter MCP Server

Endpoints

POST /mcp — the MCP Streamable HTTP endpoint (stateless). Requires a bearer token unless MCP_DISABLE_AUTH is set — see Authentication.
GET / and GET /health — health checks.
OAuth: /.well-known/oauth-authorization-server, /.well-known/oauth-protected-resource, /register, /authorize, /token, /revoke.

Run as a local MCP server (recommended)

Runs over stdio from your machine's residential IP — the configuration that actually reaches StreetEasy.

npm install
npm run build
# register with Claude Code (uses the stdio entry point):
claude mcp add streeteasy -- node "$(pwd)/dist/stdio.js"

Then ask Claude to search rentals. To run the stdio server by hand:

npm run start:stdio

Run as an HTTP server

npm install
npm run build
npm start            # listens on $PORT (default 3000), POST /mcp

Test it with the MCP SDK client (see test-client.mjs):

MCP_URL=http://localhost:3000/mcp node test-client.mjs

Configuration

Env var	Purpose
`PORT`	Port to listen on. Railway sets this automatically.
`PUBLIC_BASE_URL`	Public origin the server is reachable at (the OAuth issuer), e.g. `https://streeteasy-mcp-production.up.railway.app`. Defaults to `https://$RAILWAY_PUBLIC_DOMAIN` on Railway, else `http://localhost:$PORT`.
`MCP_DISABLE_AUTH`	Set to `1`/`true` to disable OAuth and leave `/mcp` open (handy for local testing with the bundled `test-client.mjs`).
`STREETEASY_PROXY`	Optional. HTTP/HTTPS proxy for all upstream StreetEasy calls, e.g. `http://user:pass@host:port`. Required for cloud/datacenter deploys — use a residential proxy. `HTTPS_PROXY` / `ALL_PROXY` are also honored.

Authentication (OAuth 2.1 + Dynamic Client Registration)

The HTTP transport requires OAuth by default — MCP clients (Claude, etc.) run the standard authorization flow automatically, so you usually don't configure anything. The server is a self-contained OAuth 2.1 authorization server:

Advertises metadata at /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource.
Supports Dynamic Client Registration (RFC 7591) at /register, so clients self-register with no manual client_id / client_secret.
/authorize (PKCE S256 required) → /token (authorization-code + refresh), with /revoke for revocation.
Unauthenticated POST /mcp returns 401 with a WWW-Authenticate header pointing at the protected-resource metadata, which kicks off discovery + DCR.

Because the tools expose only public listing data, there's no per-user login: authorization is auto-approved and the issued bearer token simply gates /mcp. Tokens are held in memory (single replica); a restart just makes clients transparently re-register. Set MCP_DISABLE_AUTH=1 to turn the whole layer off.

Proxy / bot-detection

StreetEasy 403s datacenter IPs, so any cloud host (Railway included) must send upstream requests through a residential proxy. Set STREETEASY_PROXY to a proxy URL (credentials may be embedded, e.g. http://user:pass@host:port) and all StreetEasy GraphQL traffic is tunnelled through it. On startup the server logs the proxy in use with credentials redacted (Outbound proxy: http://***:***@host:port).

Rotating residential proxies hand out a fresh exit IP per connection, and a clean IP isn't guaranteed every time, so the client automatically retries a 403 bot-challenge (up to 3 times when a proxy is set) to land on a good IP. A local stdio server on a residential connection doesn't need a proxy.

Deploy on Railway

This repo ships a Dockerfile. With the Railway CLI:

railway login
railway init --name streeteasy-mcp
# Cloud hosts are datacenter IPs — set a residential proxy so calls aren't 403'd:
railway variables --set "STREETEASY_PROXY=http://user:pass@host:port"
railway up
railway domain          # generate a public URL
# Set the OAuth issuer to your public URL (or rely on RAILWAY_PUBLIC_DOMAIN):
railway variables --set "PUBLIC_BASE_URL=https://<your-app>.up.railway.app"

Connect from Claude Code

claude mcp add --transport http streeteasy https://<your-app>.up.railway.app/mcp

The client discovers the OAuth endpoints and registers itself automatically (Dynamic Client Registration) — no client_id / token to configure.

Available Tools

4 tools

get_rental_detailsGet StreetEasy rental detailsB

Fetch full details for a single rental listing by its id (the id field from search_rentals results). Returns description, full amenities/features, pricing history, building info, nearby transit & schools, and media: media.photoUrls and media.floorPlanUrls (CDN image URLs), media.videoLinks (YouTube/Vimeo watch URLs + thumbnails), and media.tour3dUrl (3D walkthrough) when available.

ParametersJSON Schema

Name	Required	Description	Default
`listingId`	Yes	The StreetEasy rental listing id, e.g. '5072403'.

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It describes the return value but omits behavioral traits such as read-only nature, authentication requirements, rate limits, or error cases. For a read endpoint, this is a significant gap.

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

Conciseness3/5

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

The description is a single dense sentence that lists many return fields. While not verbose, it could be restructured (e.g., bullet points) for improved readability. It is not wasteful but could be more scannable.

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?

Given a single parameter and no output schema, the description provides a fairly comprehensive list of what is returned. It covers major sections of the response, though details like field types or nested structures are not specified. Overall, it is sufficient for an agent to understand the tool's purpose and output.

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 coverage is 100% with a single parameter described. The description adds marginal value by clarifying the id comes from search_rentals results and providing an example, but the schema already explains the parameter adequately.

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 fetches full details for a single rental listing by id, and enumerates the returned data (description, amenities, pricing history, building info, transit, schools, media). It distinguishes itself from siblings like search_rentals (broad search) and list_amenities/list_areas (categorical listings).

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 instructs to use the `id` from search_rentals results, implying a prerequisite. However, it does not explicitly state when not to use this tool or mention alternatives beyond the sibling context.

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

list_amenitiesList StreetEasy amenitiesA

List the valid amenity enum tokens accepted by search_rentals (e.g. WASHER_DRYER, DOORMAN, GYM, PRIVATE_OUTDOOR_SPACE).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/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 does not mention side effects, permissions, or stability of the list. However, as a read-only list operation, the description is adequate but not rich.

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?

Single sentence, direct, and to the point. No unnecessary words, and examples are provided for clarity.

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 parameter-less tool with no output schema, the description sufficiently covers what is returned and its purpose. It could explicitly state the return format, but examples make it clear.

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

Parameters4/5

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

There are no parameters, so schema coverage is 100%. The description adds value by explaining that the output is meant for use with search_rentals, justifying the tool's existence.

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?

Description clearly states it lists valid amenity tokens for search_rentals, providing examples. This distinguishes it from sibling tools like search_rentals (which consumes the tokens) and other list tools.

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 implies the tool should be used before constructing search_rentals queries with amenity filters. It does not explicitly state when not to use it or mention alternatives, but the purpose is narrow and clear.

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

list_areasList StreetEasy areasA

List StreetEasy area names and their numeric codes for use in search_rentals. Optionally pass a search term to filter (e.g. 'brooklyn', 'harlem', 'williams'). Names are matched case/spacing-insensitively.

ParametersJSON Schema

Name	Required	Description	Default
`search`	No	Optional substring to filter area names (case-insensitive).

TDQS

A4.5/5.0

Behavior4/5

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

Discloses matching behavior (case/spacing-insensitivity) and that it returns names and codes. With no annotations, this adequately conveys the read-only, non-destructive nature of the tool.

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?

Three short sentences, front-loaded with purpose. No redundant words, every sentence serves a clear function.

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

Completeness5/5

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

For a simple list tool with one optional parameter and no output schema, the description fully covers what the agent needs: purpose, parameter usage, return content, and integration with sibling tool.

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

Parameters4/5

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

Schema covers 100% of parameters, but description adds value by explaining how the search parameter works (case/spacing-insensitive matching, examples). Adds meaning beyond 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?

Explicitly states 'List StreetEasy area names and their numeric codes' with a specific verb and resource. Clearly distinguishes from sibling tools like search_rentals by focusing on area codes for use in that tool.

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?

States the tool is 'for use in search_rentals' and describes optional filtering with examples. Does not explicitly exclude alternatives but clearly implies the context of retrieving area codes for rental searches.

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

search_rentalsSearch StreetEasy rentalsA

Search active NYC rental listings on StreetEasy with filters. Areas accept names (e.g. 'MANHATTAN', 'Williamsburg', 'upper east side') or numeric area codes — use list_areas to discover them. Amenities are uppercase enum tokens — use list_amenities. Returns a compact list of listings plus a totalCount; paginate with page/perPage. Each listing has an id you can pass to get_rental_details, plus leadPhotoUrl and photoUrls (ready-to-view image URLs) and a url to the listing page.

ParametersJSON Schema

Name	Required	Description
`areas`	No	Neighborhoods/boroughs to search. Names or numeric codes. E.g. ['MANHATTAN'] or ['WILLIAMSBURG','LONG_ISLAND_CITY'].
`minPrice`	No	Minimum monthly rent in USD.
`maxPrice`	No	Maximum monthly rent in USD.
`minBedrooms`	No	Minimum bedrooms (0 = studio).
`maxBedrooms`	No	Maximum bedrooms.
`minBathrooms`	No	Minimum bathrooms.
`maxBathrooms`	No	Maximum bathrooms.
`amenities`	No	Required amenities (uppercase enum tokens, e.g. WASHER_DRYER, DOORMAN, GYM). See list_amenities.
`petsAllowed`	No	Only listings that allow pets.
`noFeeOnly`	No	Only no-broker-fee listings (applied to the returned page).
`sortBy`	No	Sort attribute. Default RECOMMENDED.
`sortDirection`	No	Sort direction. Default DESCENDING.
`perPage`	No	Results per page (default 20, max 100).
`page`	No	Page number (1-based).

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses the return structure (compact list, totalCount, pagination, image URLs, url) and the read-only nature implicitly. Lacks explicit statements about auth or rate limits, but sufficient for a search tool.

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?

Single paragraph with no fluff. Every sentence adds necessary information: purpose, area/amenity inputs, pagination, output fields. Front-loaded with main purpose.

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

Completeness5/5

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

Given 14 parameters with full schema coverage and no output schema, the description adequately covers the tool's functionality: filters, valid inputs via sibling tools, pagination, and key output fields. Complete for a search tool context.

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

Parameters4/5

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

Schema description coverage is 100%, but the description adds value by clarifying areas accept names or numeric codes, amenities are uppercase enum tokens, and directs to sibling tools for valid values. Also explains pagination parameters and output fields.

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 it searches active NYC rental listings with filters. It distinguishes itself from siblings (get_rental_details, list_amenities, list_areas) by specifying the search and filter functionality.

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?

Provides guidance on using list_areas and list_amenities to discover valid inputs, and explains pagination. However, it does not explicitly state when not to use this tool or provide exclusion criteria.

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.

4 tool updatesv0.1.0Jun 13, 2026
- First observedget_rental_details
- First observedlist_amenities
- First observedlist_areas
- First observedsearch_rentals

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Scored 2026-06-13 21:20 across 4 tools

Disambiguation5/5

Each tool has a distinct purpose: search_rentals for querying listings, get_rental_details for full info on a specific listing, and list_amenities/list_areas for retrieving valid filter values. No overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (get_rental_details, list_amenities, list_areas, search_rentals), making them predictable and uniform.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose of browsing NYC rental listings. It covers searching, detail retrieval, and necessary enum lookups without bloat or insufficiency.

Completeness5/5

The tool surface provides a complete workflow: discover valid filters (amenities/areas), search listings with those filters, and get full details for any listing. No obvious gaps for a read-only rental search API.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
mcp-server B
cc.thecolony
Remote MCP server for The Colony — a social network for AI agents (posts, DMs, search, marketplace).
Knowledge & Memory Research & Data
22323
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
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

Related MCP Servers

Rentalot MCP Serverofficial
Real Estate CRM
Rentalot-ai
A
license
Not graded
quality
C
maintenance
MCP server for the Rentalot API. Manage rental properties, contacts, showings, conversations, and more from any AI assistant.
Updated 5 months ago (2026-04-09 00:30 UTC)
15
1
MIT
Apartment Hunter MCP Server
Real Estate Web Scraping
ai-engineers-guild
A
license
A
quality
B
maintenance
An MCP server for rental apartment aggregation, enabling geographic polygon search, semantic vector search, and LLM-powered analysis. Integrates with AI agents like Claude Desktop to manage apartment hunting workflows.
Updated 19 days ago (2026-08-23 16:25 UTC)
15
2
MIT
supost-mcp
E-commerce & Retail Search
Capmus-Team
F
license
Not graded
quality
B
maintenance
Remote MCP server for SUpost, the Stanford student marketplace. Lets AI agents search active listings, fetch listing details, and read verified market statistics.
Updated a month ago (2026-07-27 17:43 UTC)
-
vastai-mcp
dam2452
F
license
A
quality
B
maintenance
MCP server that wraps the Vast.ai REST API to enable LLM agents to search GPU marketplace, rent machines, manage instance lifecycle, run commands, and inspect billing.
Updated 2 months ago (2026-07-20 07:13 UTC)
20
1
-

streeteasy-mcp

Tools

Media

Not included: contact info & inquiries

Endpoints

Run as a local MCP server (recommended)

Run as an HTTP server

Configuration

Authentication (OAuth 2.1 + Dynamic Client Registration)

Proxy / bot-detection

Deploy on Railway

Connect from Claude Code

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Rentalot MCP Serverofficial