RentCast MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.9/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
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 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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![RentCastMCP MCP server](https://glama.ai/mcp/servers/bfhayes/RentCastMCP/badges/card.svg)](https://glama.ai/mcp/servers/bfhayes/RentCastMCP)

Score Badge

Copy to your README.md:

[![RentCastMCP MCP server](https://glama.ai/mcp/servers/bfhayes/RentCastMCP/badges/score.svg)](https://glama.ai/mcp/servers/bfhayes/RentCastMCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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