Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@RentCast MCP Server (unofficial) Get rent estimate for 123 Main St, Austin, TX and compare to zip code average."
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.
An MCP server that lets Claude (or any MCP client) query the RentCast property API — rent and sale-value estimates, market stats, property records, and active listings — through six read-only tools.
Read-only. All six tools only read; nothing here can change a RentCast account.
A curated six, not a 1:1 API dump. These are the endpoints that make the best agent workflows, described so the model chains them correctly (e.g. list_active_listings → get_rent_estimate per address → rank by upside).
Clean errors. A bad key, an inactive subscription, or a rate-limit comes back as a plain sentence the agent can act on, not a stack trace.
Related MCP server: RentCast MCP Server
git clone https://github.com/hasankhadra/rentcast-mcp.git
cd rentcast-mcp
npm install && npm run buildThen add this to your Claude Desktop config — ~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows — and fully restart Claude Desktop:
{
"mcpServers": {
"rentcast": {
"command": "node",
"args": ["/absolute/path/to/rentcast-mcp/dist/index.js"],
"env": {
"RENTCAST_API_KEY": "your_rentcast_api_key"
}
}
}
}Replace the path with where you cloned the repo, and the key with your own from app.rentcast.io (the free tier is 50 requests/month — keep limit values modest). The six rentcast tools appear in the tools menu once Claude Desktop restarts.
Tool | What it does |
| Search property records by address, city/state, zip, or lat-long + radius. |
| Full attributes for one property, by RentCast id or address. |
| Long-term monthly rent estimate (AVM) for an address, with comparables. |
| Sale-price (market value) estimate (AVM) for an address, with comparables. |
| Zip-level sale & rental market stats — averages, days on market, listing counts. |
| Currently active |
All tools are read-only. Prices are USD; rents are USD/month; areas are square feet.
Once it's wired into Claude Desktop, ask:
"What's the rent estimate for 5500 Grand Lake Dr, San Antonio, TX 78244? How does it compare to the zip code's average rent?"
Claude calls get_rent_estimate for the address and get_market_stats for 78244, then compares — e.g. an estimated ~$1,630/mo against the zip's ~$1,555/mo average.
And the one a human can't do in a single step against the RentCast dashboard:
"Find 3-bed active rental listings in Austin, TX under $2,500/mo, and estimate the fair-market rent for each so I can spot the underpriced ones."
Claude calls list_active_listings (rental, Austin TX, 3 bed), filters by price, then fans out get_rent_estimate per address and ranks by the gap between asking rent and estimated rent — chaining tools across the API in a way the dashboard doesn't.
npm run build # compile TypeScript → dist/
npm run dev # tsc --watch
npm start # run the built server on stdioLayout: src/rentcastClient.ts is the single HTTP/auth/error layer; each tool lives in its own file under src/tools/; src/index.ts registers them and opens the stdio transport. For local testing outside Claude Desktop, copy .env.example to .env and run RENTCAST_API_KEY=... npm start.
Unofficial — built to show what an official RentCast MCP server could look like. Want it official — OAuth, full tool set, maintained under your name? Hasan Khadra · hk@hasankhadra.me · hasankhadra.me/mcp
Get aggregate market statistics and trends for a ZIP CODE — average and median sale price, average and median rent, price/rent per square foot, average days on market, and listing counts. Use this to establish the local baseline: e.g. compare a single property's get_rent_estimate against the zip's average rent, or gauge whether an area is hot (low days-on-market, many new listings). Choose data_type to get sale stats, rental stats, or both. All prices are USD; rents are USD/month. Returns a summarized snapshot; if RentCast has too little data for a zip, the corresponding sale or rental block is omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| zip_code | Yes | The 5-digit US zip code to pull market statistics for, e.g. '78244'. | |
| data_type | No | Which stats to return: 'Sale', 'Rental', or 'All' (default). | |
| history_range | No | Months of historical trend data to consider (default 12). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses return behavior (summarized snapshot, omitted blocks when data is sparse), currency units (USD, rents per month), and data_type effects. It doesn't cover rate limits or auth, but these are likely common to all tools. The core behavioral aspects are well covered.
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 five sentences, front-loaded with the tool's purpose, then usage guidance, then return semantics. Every sentence earns its place; there is no redundancy or 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?
Given there is no output schema, the description offers a complete picture: what metrics are returned, the units, how data_type affects output, and what happens when data is insufficient. For a moderate-complexity stats tool, this is fully sufficient.
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 all parameters with descriptions (100% coverage), so baseline is 3. The description adds value by clarifying data_type options ('sale stats, rental stats, or both') and the purpose of zip_code as a geographic baseline. history_range is not explicitly described in the description, but the schema covers it adequately.
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's function: 'Get aggregate market statistics and trends for a ZIP CODE' and lists specific metrics (sale/rent prices, days on market, etc.). It is distinct from sibling tools, which focus on individual properties or listings, and even mentions a sibling (get_rent_estimate) for comparison.
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 says when to use the tool: 'Use this to establish the local baseline' and gives concrete examples (comparing a property's rent estimate, gauging whether an area is hot). It does not include explicit when-not-to-use or alternative tools, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the FULL record for a single property — all structural attributes (type, beds, baths, square footage, lot size, year built), features, tax assessments and amounts, last sale price/date, and owner info where available. Look a property up either by its RentCast id (from search_properties) or directly by address. Use this after search_properties to drill into one property, or on its own when you already have the exact address. Returns the complete record as JSON; prices are USD, areas are in square feet. This is a property RECORD, not a for-sale/rent listing.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | The RentCast property id (from search_properties), e.g. '5500-Grand-Lake-Dr,...'. | |
| address | No | The full property address, in the format 'Street, City, State, Zip'. Provide this OR id — id is used if both are given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses return format ('Returns the complete record as JSON; prices are USD, areas are in square feet'), data completeness caveats ('owner info where available'), and clarifies the scope ('single property'). It does not mention id/address precedence, which is already covered in the schema.
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 moderately long but each sentence provides distinct value: what the tool fetches, how to look up, when to use it, return format, and what it is not. It is front-loaded with the core purpose and avoids redundancy.
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?
No output schema exists, so the description effectively explains expected return content by listing structural attributes, features, tax assessments, last sale, and owner info. It also clarifies units and data availability, making the tool's behavior sufficiently predictable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are well-documented in the schema. The description restates the two lookup options (id or address) but does not add extra meaning beyond what the schema already provides, such as formats or precedence details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Fetch the FULL record for a single property' and lists concrete attributes. It explicitly distinguishes from siblings by stating 'This is a property RECORD, not a for-sale/rent listing', making the tool's scope unambiguous.
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 provides clear when-to-use guidance: 'Use this after search_properties to drill into one property, or on its own when you already have the exact address.' It also warns against using it for listings, though it does not explicitly name alternative tools like get_rent_estimate or list_active_listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the fair-market LONG-TERM monthly rent for a property using RentCast's AVM (automated valuation model). Give an address, or a lat/long. For the sharpest estimate, also pass the property's propertyType, bedrooms, bathrooms, and squareFootage — or set lookup_subject_attributes=true to have RentCast look those up automatically before estimating. Returns the point rent estimate plus a low–high range (all USD per month) and the top comparable rentals the model used (address, rent, beds/baths, square footage, distance in miles). This is the core valuation tool — pair it with get_market_stats to compare an estimate against the zip-code average, or call it per-listing to rank rental opportunities.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | Full address in 'Street, City, State, Zip' format, e.g. '5500 Grand Lake Dr, San Antonio, TX, 78244'. Provide this OR latitude+longitude. | |
| bedrooms | No | Bedrooms of the subject (use 0 for a studio). | |
| latitude | No | Latitude, if not using address. Must be paired with longitude. | |
| bathrooms | No | Bathrooms of the subject (fractions allowed, e.g. 2.5). | |
| longitude | No | Longitude, if not using address. Must be paired with latitude. | |
| comp_count | No | How many comparable rentals to base the estimate on (5-25, default 15). | |
| property_type | No | Property type of the subject, for a better-matched estimate. | |
| square_footage | No | Living area of the subject, in square feet. | |
| lookup_subject_attributes | No | If true, RentCast looks up the subject's beds/baths/type/sqft from its records before estimating — use when you only have an address and want the model to self-fill attributes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the AVM mechanism, mentions automatic lookup via lookup_subject_attributes, and discloses return contents ('point rent estimate plus a low–high range ... and the top comparable rentals'). It does not disclose failure modes or rate limits, but it clearly describes observable behavior for a read-only estimation tool.
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 paragraph that front-loads the main purpose, then covers input, recommendations, output, and usage context. No filler words, but it is somewhat long and could be tightened. Still, every sentence earns its place.
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 9 parameters and no output schema, the description sufficiently covers the main intent, input alternatives, optional parameter improvements, output structure, and complementary sibling usage. It doesn't mention every parameter (e.g., comp_count) but the schema fully defines those, and the description adds the missing high-level context about AVM behavior and return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds valuable relationships: 'For the sharpest estimate, also pass the property's propertyType, bedrooms, bathrooms, and squareFootage — or set lookup_subject_attributes=true' and 'Give an address, or a lat/long.' This explains how parameters interact and which combinations are recommended, exceeding schema-only descriptions.
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 opens with a specific verb+resource: 'Estimate the fair-market LONG-TERM monthly rent for a property using RentCast's AVM.' This clearly distinguishes it from sibling get_value_estimate, which would be for property value rather than rent, and the explicit 'rent' and 'LONG-TERM monthly rent' phrases make the tool's purpose unambiguous.
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?
Provides explicit usage context: 'pair it with get_market_stats to compare an estimate against the zip-code average, or call it per-listing to rank rental opportunities.' It also offers input-method guidance ('Give an address, or a lat/long') and suggests parameter improvements for a sharper estimate. Missing a direct 'when not to use' or comparison with get_value_estimate, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the current SALE (market) value of a property using RentCast's AVM. This is the sale-price counterpart to get_rent_estimate. Give an address or a lat/long; optionally pass the subject's propertyType, bedrooms, bathrooms, and squareFootage, or set lookup_subject_attributes=true to have RentCast fill them in. Returns the point value estimate plus a low–high range (all USD) and the top comparable SALES the model used (address, price, beds/baths, square footage, distance in miles). Use to gauge what a property is worth, to compute a rent-to-value / gross-yield ratio alongside get_rent_estimate, or to sanity-check a list price.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | Full address in 'Street, City, State, Zip' format. Provide this OR latitude+longitude. | |
| bedrooms | No | Bedrooms of the subject (use 0 for a studio). | |
| latitude | No | Latitude, if not using address. Must be paired with longitude. | |
| bathrooms | No | Bathrooms of the subject (fractions allowed, e.g. 2.5). | |
| longitude | No | Longitude, if not using address. Must be paired with latitude. | |
| comp_count | No | How many comparable sales to base the estimate on (5-25, default 15). | |
| property_type | No | Property type of the subject, for a better-matched estimate. | |
| square_footage | No | Living area of the subject, in square feet. | |
| lookup_subject_attributes | No | If true, RentCast looks up the subject's attributes from its records before estimating — use when you only have an address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the return payload (point estimate, low–high range, comparable sales with attributes) and input alternatives (address vs lat/long, lookup_subject_attributes). While it does not mention side effects, permissions, or rate limits, the read-only nature is strongly implied by the word 'estimate' and the described 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?
At about 130 words across four sentences, the description is appropriately sized for a 9-parameter tool. Every sentence earns its place: purpose, sibling relationship, input options, return details, and use cases. It could be slightly more structured (e.g., bullet points), but it is not wasteful or redundant.
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?
Despite having no output schema and no annotations, the description is remarkably complete. It covers the tool's purpose, input flexibility (address or coordinates, optional attributes), the effect of lookup_subject_attributes, the return shape (point value, range, comparable sales), and practical use cases. This is more than sufficient for an agent to select and invoke the tool correctly in most scenarios.
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 schema has 100% coverage with detailed parameter descriptions, so the baseline is 3. The description adds semantic value by grouping optional subject attributes (propertyType, bedrooms, bathrooms, squareFootage) and explaining the shortcut of setting lookup_subject_attributes=true. This helps an agent understand the intended filing-in strategy beyond what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Estimate the current SALE (market) value') and resource ('RentCast's AVM'), and explicitly positions itself as the sale-price counterpart to get_rent_estimate. This clearly distinguishes it from sibling tools like get_rent_estimate and get_market_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?
The description provides explicit use cases: gauging what a property is worth, computing a rent-to-value / gross-yield ratio alongside get_rent_estimate, or sanity-checking a list price. It also names the closest sibling (get_rent_estimate) as a counterpart, giving an agent clear guidance on when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List CURRENTLY ACTIVE sale or rental listings for an area — the real, on-market inventory (unlike search_properties, which searches historical property records). Set listing_type to 'sale' or 'rental' to choose the market. Scope by city+state and/or zip code, and filter by bedrooms, bathrooms, and property type. Returns a summarized list (id, address, price, beds/baths, square footage, days on market, status), most recently seen first. Prices are USD (a total sale price for 'sale', a monthly rent for 'rental'). NOTE: RentCast does not filter by price server-side — request the listings, then filter/rank by the returned price yourself. This is the entry point for workflows like 'find 3-bed listings in under $X, then estimate rent for each' — feed each result's address to get_rent_estimate.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name, e.g. 'Austin'. Use together with state. | |
| limit | No | Max listings to return (1-500, default 20). Keep modest — each downstream rent estimate is a separate API call against your quota. | |
| state | No | 2-character state abbreviation, e.g. 'TX'. Use together with city. | |
| bedrooms | No | Bedrooms: exact ('3'), range ('3-5'), or list ('2,3,4'). | |
| zip_code | No | 5-digit US zip code to scope the search. | |
| bathrooms | No | Bathrooms: exact ('2'), range ('1-3'), or list. Fractions allowed. | |
| listing_type | Yes | 'sale' for homes for sale, 'rental' for long-term rentals. | |
| property_type | No | Filter to a single property type. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so impressively. It discloses that RentCast does not filter by price server-side and the agent must filter/rank by returned price. It also reveals ordering (most recently seen first), price units (USD, sale total vs monthly rent), and downstream API cost implications for 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?
The description is information-dense yet compact. It front-loads the core purpose, then covers scoping, return format, key caveats, and a workflow example. Every sentence earns its place without fluff or repetition.
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 an 8-parameter tool with no output schema, the description is remarkably complete. It specifies the return structure (id, address, price, beds/baths, square footage, days on market, status), explains the price filter absence, and shows how the tool fits into a larger workflow with sibling tools. No critical gaps remain.
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?
Though schema coverage is 100%, the description adds meaningful context: it explains how listing_type selects the market, how city+state work together, and warns that keeping limit modest matters because each downstream rent estimate is a separate API call. This goes beyond the schema's raw parameter definitions.
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 the tool lists currently active sale or rental listings with a clear verb+resource+scope ('List CURRENTLY ACTIVE sale or rental listings for an area'), and explicitly distinguishes it from search_properties, which searches historical property records. This makes the purpose unambiguous and differentiates it from a sibling.
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 says when to use this tool ('entry point for workflows') and provides a concrete example: 'find 3-bed listings in <city> under $X, then estimate rent for each' — feed each result's address to get_rent_estimate. It also explicitly contrasts with search_properties, offering an alternative and exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search RentCast's property records database — the underlying county/MLS-sourced record for real US homes (NOT active listings; use list_active_listings for what's for sale/rent). Filter by a single address, or by a city+state, a zip code, or a lat/long + radius, then narrow with propertyType, bedrooms, bathrooms, or square footage. Returns a summarized list of matching properties (id, address, type, beds/baths, square footage, year built, last sale). Use the returned id or address with get_property_details for full attributes. Bedrooms/bathrooms/squareFootage accept an exact value ('3'), a range ('3-5'), or a list ('2,3,4'). Prices are USD; square footage is in square feet.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name, e.g. 'Austin'. Use together with state. | |
| limit | No | Max records to return (1-500, default 20). Keep low to conserve API quota. | |
| state | No | 2-character state abbreviation, e.g. 'TX'. Use together with city. | |
| address | No | A full address to look up, in the format 'Street, City, State, Zip' (e.g. '5500 Grand Lake Dr, San Antonio, TX, 78244'). Overrides the area filters. | |
| bedrooms | No | Bedrooms: exact ('3'), range ('3-5'), or list ('2,3,4'). Use 0 for studios. | |
| zip_code | No | 5-digit US zip code, e.g. '78244'. | |
| bathrooms | No | Bathrooms: exact ('2'), range ('1-3'), or list. Fractions allowed ('2.5'). | |
| property_type | No | Filter to a single property type. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it includes filter capabilities (lat/long, radius, square footage) that do not exist in the input schema. This is misleading about the tool's actual behavior. It does mention the summarized output and units, but the inaccuracies significantly reduce transparency.
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 moderately concise and front-loaded with the main purpose. However, it includes extraneous details about non-existent filters, which adds confusion rather than value. It could be shorter and more accurate.
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?
The description is incomplete because it omits how filters combine and misleadingly includes unsupported filters. It also does not explain that address overrides area filters in the main text (only in the schema). For a tool with 8 parameters and no output schema, the description should be more precise and cover actual invocation constraints.
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 value formats for bedrooms and bathrooms. The description repeats that information and adds irrelevant parameters (lat/long, squareFootage) that are not in the schema, which can confuse an agent into using unsupported arguments. No meaningful added semantics for the actual parameters.
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 searches RentCast's property records database and explicitly distinguishes it from active listings by instructing to use list_active_listings instead. The verb 'Search' plus the resource 'property records database' makes the purpose specific and unambiguous.
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 provides explicit guidance on when to use this tool versus list_active_listings, and advises using the returned id or address with get_property_details for full attributes. This directly addresses alternatives and complements sibling tools effectively.
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.
v0.1.0get_market_statsget_property_detailsget_rent_estimateget_value_estimatelist_active_listingssearch_propertiesScored across 6 tools
Each tool serves a clearly distinct purpose: searching property records, fetching full property details, estimating rent, estimating sale value, getting market stats, and listing active listings. The descriptions explicitly contrast related tools (e.g., search_properties vs. list_active_listings) so an agent will not confuse them.
All tool names follow a consistent verb_noun pattern with lowercase and underscores: get_property_details, search_properties, get_rent_estimate, get_value_estimate, get_market_stats, list_active_listings. The verbs vary (get, search, list) but the style is uniform and predictable.
Six tools is well-scoped for a real estate data API, covering search, details, valuation, market stats, and listings without unnecessary bloat. Each tool has a concrete role, and the count feels appropriate for the domain.
The tool set covers the core workflows: lookup a property (search_properties), get its full record (get_property_details), estimate rent and value, compare against market stats, and find active listings. There are no obvious dead ends; listings feed into estimates via the returned addresses, and stats provide context.
Rentcast MCP — wraps Rentcast API (api.rentcast.io/v1)
U.S. real-estate data: property records, AVM value + rent estimates, sale/rental listings.
Redfin listings, sale-comps, and neighborhood market data via natural-language queries.
Redfin for-sale, for-rent and sold listings plus full property pages, as structured JSON.
