Click on "Install 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 search for 3-bedroom homes for sale under $500k in Austin, TX"
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.
MCP server that wraps the RentCast API to help search for houses for sale, get property valuations, rent estimates, and market statistics.
# Install dependencies
uv sync
# Set your API key
export RENTCAST_API_KEY="your-api-key-here"Get an API key at app.rentcast.io.
Related MCP server: RentCast MCP Server
# stdio transport (default, for Claude Desktop / Claude Code)
uv run rentcast-mcp
# Or directly
uv run python -m rentcast_mcpAdd to your claude_desktop_config.json:
{
"mcpServers": {
"rentcast": {
"command": "uv",
"args": ["--directory", "/path/to/rentcast-mcp", "run", "rentcast-mcp"],
"env": {
"RENTCAST_API_KEY": "your-api-key-here"
}
}
}
}Tool | Description |
| Search homes for sale by location, price, beds, baths, sqft, year built |
| Full details for a specific listing by ID |
| Property records with owner info, tax history, sale history |
| Automated value estimate (AVM) with comparable sales |
| Rental value estimate for investment analysis |
| Market statistics and price trends for a zip code |
| Side-by-side comparison of multiple listings |
| Search recently sold properties (comps) |
# Search listings
uv run python cli.py search_sale_listings '{"zipCode": "95123", "minBedrooms": 4, "maxPrice": 2100000}'
# Get property value
uv run python cli.py get_property_value '{"address": "5500 Grand Lake Dr, San Antonio, TX, 78244"}'
# Market stats
uv run python cli.py get_market_stats '{"zipCode": "78701"}'
# Rent estimate
uv run python cli.py get_rent_estimate '{"address": "123 Main St, Austin, TX 78701"}'
# Compare listings
uv run python cli.py compare_listings '{"listing_ids": ["id1", "id2"]}'Free tier: 50 API calls/month. The server tracks call count per session and warns when approaching the limit.
Compare multiple sale listings side-by-side for easy evaluation.
Args: listing_ids: List of RentCast listing IDs to compare (2-10 listings recommended)
| Name | Required | Description | Default |
|---|---|---|---|
| listing_ids | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the comparison function and a recommended range, but does not mention whether the operation is read-only, what happens if invalid IDs are provided, or any limitations on the input. This is a significant gap for a tool that still has side-effect expectations.
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 highly concise, with two short sentences and a one-line Args section. It front-loads the primary purpose and the only parameter, with no wasted words. The structure is efficient and easy to parse.
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 tool is simple with a single parameter and an output schema, so the description covers the main inputs. However, it lacks any mention of what fields are compared, returns, or edge-case behavior. Given the presence of an output schema, the description is minimally adequate but leaves room for more context about the comparison scope.
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 provides only a list of strings with the title 'Listing Ids', but the description adds meaning by explaining these are 'RentCast listing IDs' and recommending a 2-10 count. This clarifies the expected format and purpose of the parameter, going beyond the raw 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?
The description clearly states 'Compare multiple sale listings side-by-side for easy evaluation', which identifies the specific verb (compare) and resource (sale listings). This distinguishes it from sibling tools that fetch details or search listings, making 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?
The description implies usage when you need to evaluate multiple listings by comparing them, but it does not explicitly state when to use this tool versus alternatives like get_listing_details or search_sale_listings. It does provide a practical usage guideline with the recommended 2-10 listing ID range, so the context is minimally guiding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a specific sale listing by its RentCast ID.
Args: listing_id: The RentCast listing ID (returned by search_sale_listings)
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only says 'get full details' but does not disclose any behavior such as error handling, required permissions, read-only nature, or potential side effects. The name implies a read operation, but beyond that, transparency is minimal.
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, front-loaded with the purpose, and includes a simple 'Args' section. Every word earns its place with 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?
For a simple one-parameter get tool, the description is sufficient: it explains what the tool does, what the parameter is, and where to obtain it. The presence of an output schema covers return values. It lacks only extra context like error behavior, but overall it is complete enough for straightforward use.
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 only defines listing_id as a string with no explanation. The description adds essential meaning by identifying it as a RentCast listing ID and noting it comes from search_sale_listings, which is valuable context beyond 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?
The description clearly states the tool fetches full details for a specific sale listing by its RentCast ID. This distinguishes it from sibling tools like search_sale_listings (which lists) and get_property_record (which returns property data), giving a specific verb+resource+scope.
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 mentions the listing_id is returned by search_sale_listings, which implies this tool is used after search and when full details are needed. However, it does not explicitly exclude other scenarios or mention alternatives, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregate market statistics and price trends for a zip code.
Args: zipCode: 5-digit zip code to get market data for historyRange: Number of months of history to include (1-24, default 12)
| Name | Required | Description | Default |
|---|---|---|---|
| zipCode | Yes | ||
| historyRange | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It clearly indicates a read operation ('Get') and adds useful constraints (historyRange 1-24, default 12), but omits details such as data source, update frequency, or response aggregation specifics. This 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a single substantive sentence for purpose, followed by a concise argument list. No wasted words or 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?
Given the tool's simplicity and the presence of an output schema, the description adequately covers purpose and parameters. It lacks comparative usage notes (which affect Usage Guidelines) and data source details, but these are not critical for a straightforward stats 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?
The description fully explains both parameters: zipCode is a 5-digit code, and historyRange specifies months (1-24, default 12). This compensates completely for the schema's 0% description coverage, adding format, range, and default behavior.
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 'Get aggregate market statistics and price trends for a zip code' – a specific verb, resource (market statistics), and scope (zip code). This clearly distinguishes it from sibling tools like get_property_value or get_rent_estimate, which focus on individual properties.
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 context of zip-code-level aggregate data is explicit, making it obvious when to choose this over listing-specific tools. However, it does not name alternatives or provide explicit when-not-to-use guidance, falling 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.
Get property records including tax history, owner info, and sale history for an address.
Args: address: Full property address (e.g., "5500 Grand Lake Dr, San Antonio, TX, 78244")
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. 'Get' implies a read-only operation, and the description discloses the data categories returned (tax history, owner info, sale history), which adds useful behavioral context. However, it does not mention any potential side effects, authentication requirements, or limitations, which would be expected for full 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 two concise sentences, front-loaded with the core purpose, and includes a clearly separated Args section. Every piece of text contributes to understanding purpose and input, with 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 the simple one-parameter interface and the availability of an output schema (which likely details return structure), the description is quite complete. It specifies the key data returned and provides an example input. A minor gap is the lack of guidance on when to choose this tool over closely related siblings, but overall it is adequate for a tool of this complexity.
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 description provides an example address ('5500 Grand Lake Dr, San Antonio, TX, 78244') and labels it as a 'full property address', going beyond the schema's minimal type declaration. This gives the agent a clear template for constructing valid input, which is valuable given the 0% schema description coverage.
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 'Get property records including tax history, owner info, and sale history for an address.' This uses a specific verb and resource, and the listed data types distinguish it from sibling tools like get_property_value or get_rent_estimate. It makes 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?
The description gives clear context: it is for retrieving comprehensive property records (tax history, owner info, sale history) for a given address. It does not explicitly mention when not to use it or compare with alternatives like get_property_value, but the data coverage implies a use case distinct from simple value or rent estimation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an automated value estimate (AVM) for a property with comparable sales.
Args: address: Full property address (e.g., "5500 Grand Lake Dr, San Antonio, TX, 78244") compCount: Number of comparable properties to include (1-25, default 10)
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| compCount | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the purpose and parameter meanings, without mentioning limitations, error conditions, or any side effects. It does not explain what happens when no comparable sales are found or how the output is structured.
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 purpose sentence followed by a concise 'Args:' block. It is front-loaded with the core function and includes no extraneous text.
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 two parameters and no annotations, the description adequately explains the purpose and parameters. It lacks usage context such as when to prefer this over get_rent_estimate and does not mention potential failure modes, but the output schema covers return format.
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 has no descriptions (0% coverage), but the description compensates by providing a full address example and clarifying compCount as the number of comparable properties with a range of 1-25 and a default of 10. This adds significant meaning beyond the schema's basic titles.
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 it retrieves an automated value estimate (AVM) for a property with comparable sales. It uses a specific verb and resource, distinguishing it from siblings like get_rent_estimate and get_property_record.
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?
No guidance is provided on when to use this tool versus alternatives such as get_rent_estimate or search_recent_sales. The description implies its use for AVM but does not mention exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a rental value estimate for investment analysis of a property.
Args: address: Full property address (e.g., "5500 Grand Lake Dr, San Antonio, TX, 78244")
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the purpose and does not mention any side effects, data sources, limitations, or typical response characteristics, leaving the agent without insight into what happens when the tool is invoked.
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 long, front-loaded with the core purpose, and includes a structured 'Args:' block that directly clarifies the only parameter. Every sentence earns its place with no redundant 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?
For a simple one-parameter tool with an output schema present, the description is reasonably complete. It clearly identifies the input and purpose, though it could benefit from a brief note about what kind of estimate (e.g., monthly rent) is returned, but the output schema likely covers that.
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 0%, but the description compensates by explaining the 'address' parameter as 'Full property address' and providing a concrete example. This adds meaning beyond the schema's bare 'string' type, helping the agent formulate correct input.
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 with a specific verb and resource: 'Get a rental value estimate for investment analysis of a property.' This distinguishes it from sibling tools like get_property_value or get_property_record, which likely serve different valuation or lookup purposes.
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 no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or contextual scenarios for choosing this tool over sibling tools like get_market_stats or search_recent_sales.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search recently sold properties (comparable sales) for pricing evaluation.
Args: zipCode: 5-digit zip code to search in address: Full address for location-based search radius: Search radius in miles (max 100) latitude: Latitude for circular search longitude: Longitude for circular search minBedrooms: Minimum number of bedrooms maxBedrooms: Maximum number of bedrooms minPrice: Minimum sale price maxPrice: Maximum sale price saleDateRange: Date range for sales in YYYY-MM-DD,YYYY-MM-DD format (e.g., "2024-01-01,2025-01-01") propertyType: Property type filter -- Single Family, Condo, Townhouse, etc. limit: Maximum results to return (1-500, default 20) offset: Pagination offset
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| radius | No | ||
| address | No | ||
| zipCode | No | ||
| latitude | No | ||
| maxPrice | No | ||
| minPrice | No | ||
| longitude | No | ||
| maxBedrooms | No | ||
| minBedrooms | No | ||
| propertyType | No | Single Family | |
| saleDateRange | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It does disclose some behavioral constraints (radius max 100, limit 1-500, default 20) and parameter formats, but omits important context like whether it's read-only, how 'recent' is defined, or what the default date range is.
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 front-loaded with a clear purpose sentence followed by a parameter list. While lengthy, each parameter line earns its place by adding meaning. No filler or 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?
The tool is complex with 13 optional parameters, and the description doesn't explain how parameters combine (e.g., zipCode vs address vs lat/long) or what the output looks like. The presence of an output schema mitigates the return-value gap, but combination rules are still 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?
The description provides a clear, one-line explanation for every parameter, significantly enriching the bare schema which has 0% description coverage. It adds practical details like 'saleDateRange' format and 'radius' limits, giving the agent actionable guidance.
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 a specific verb and resource: 'Search recently sold properties (comparable sales) for pricing evaluation.' This distinguishes it from siblings like search_sale_listings (which likely targets active listings) by emphasizing sold properties.
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 gives context ('for pricing evaluation') but lacks explicit exclusions or comparisons to comparable sibling tools. It does not state when to prefer this tool over search_sale_listings or get_property_record, leaving the decision ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for homes currently for sale by location, price range, size, and other criteria.
Args: zipCode: 5-digit zip code to search in city: City name (case-sensitive) state: 2-character state abbreviation (e.g., CA, TX) address: Full address string for precise search latitude: Latitude for circular radius search longitude: Longitude for circular radius search radius: Search radius in miles (max 100, requires lat/lng) propertyType: Property type filter -- Single Family, Condo, Townhouse, Manufactured, Multi-Family, Apartment, Land minBedrooms: Minimum number of bedrooms maxBedrooms: Maximum number of bedrooms minBathrooms: Minimum number of bathrooms maxBathrooms: Maximum number of bathrooms minPrice: Minimum listing price maxPrice: Maximum listing price minSqft: Minimum square footage maxSqft: Maximum square footage minLotSize: Minimum lot size in square feet maxLotSize: Maximum lot size in square feet minYearBuilt: Minimum year built maxYearBuilt: Maximum year built maxDaysOnMarket: Maximum days on market (min 1) status: Listing status -- Active (default) or Inactive limit: Maximum results to return (1-500, default 20) offset: Pagination offset
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| limit | No | ||
| state | No | ||
| offset | No | ||
| radius | No | ||
| status | No | ||
| address | No | ||
| maxSqft | No | ||
| minSqft | No | ||
| zipCode | No | ||
| latitude | No | ||
| maxPrice | No | ||
| minPrice | No | ||
| longitude | No | ||
| maxLotSize | No | ||
| minLotSize | No | ||
| maxBedrooms | No | ||
| minBedrooms | No | ||
| maxBathrooms | No | ||
| maxYearBuilt | No | ||
| minBathrooms | No | ||
| minYearBuilt | No | ||
| propertyType | No | Single Family | |
| maxDaysOnMarket | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It provides some constraints (e.g., radius max 100 and requiring lat/lng, limit range 1-500) and defaults (status Active). However, it omits essential behaviors such as whether at least one location parameter is required, how return data is structured, and authentication needs.
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 front-loaded with a clear summary sentence, followed by a structured, compact parameter list. Each line is concise and informative, though the list is necessarily long for 24 parameters. No redundant text exists.
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 24 parameters and an output schema, the description covers individual parameter semantics but misses relational constraints: it does not explain whether a location filter is mandatory, how city/state/zip interact, or how offset pagination behaves. The output schema covers return values, but the search combination semantics are unclear.
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 0%, and the 'Args' list compensates fully. Every parameter receives a meaningful description with constraints, allowed values (e.g., propertyType), and defaults (e.g., status). This provides far more than the schema's bare types and defaults.
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 begins with 'Search for homes currently for sale by location, price range, size, and other criteria', clearly stating the verb (search), resource (homes for sale), and scope. The phrase 'currently for sale' distinguishes it from the sibling tool 'search_recent_sales'.
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 lists broad search criteria but does not explicitly state when to use this tool over alternatives like 'search_recent_sales' or 'get_listing_details'. It implies usage through its filter parameters but lacks explicit guidance on when-not-to-use or alternative selection.
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.
v0.1.0compare_listingsget_listing_detailsget_market_statsget_property_recordget_property_valueget_rent_estimatesearch_recent_salessearch_sale_listingsEach tool targets a distinct data type and action: searching current listings, searching sold comps, fetching listing details, property records, value estimates, rent estimates, market stats, and comparing listings. Even the two search tools are clearly separated by active vs. sold status. No meaningful overlap between tools.
All tool names follow a consistent verb_noun pattern with snake_case: 'search_' for searches, 'get_' for retrievals, and 'compare_' for comparison. This is highly predictable and makes the tool set easy to navigate.
8 tools is well within the ideal 3-15 range for a focused real estate data server. Each tool covers a distinct core operation (search, detail, estimates, stats) without unnecessary bloat. The count feels perfectly scoped to the server's purpose.
The server covers the full range of read-only property data needs: active listings, recent sales, property records, valuation, rent estimation, and market trends. The only notable gap is the absence of rental listing search despite 'RentCast' branding, but this is minor given the rent estimate tool and the overall breadth.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Rentcast MCP — wraps Rentcast API (api.rentcast.io/v1)
Zillow for-sale, for-rent and sold listings, and full property details, as structured JSON.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bfhayes/RentCastMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server