redfin-mcp

by chrischall

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.10.1
Disambiguation5/5
Each tool has a clearly distinct purpose. For example, redfin_search_properties is for listing searches, redfin_get_property retrieves full records, and redfin_get_price_history focuses on price events. Even similar tools like redfin_bulk_get and redfin_compare_properties have different use cases (bulk fetch vs. side-by-side comparison). No ambiguity.
Naming Consistency5/5
All tools follow the 'redfin_' prefix and a consistent verb_noun pattern (e.g., redfin_search_properties, redfin_get_property, redfin_calculate_mortgage). There is no mixing of conventions like camelCase or inconsistent verb styles.
Tool Count5/5
With 21 tools, the server covers a broad domain including property search, details, comparisons, bulk operations, mortgage calculations, climate risk, and session management. Each tool earns its place, and the count is well-scoped without being excessive or insufficient.
Completeness5/5
The tool surface covers the full lifecycle of property interaction: search, retrieve details, price history, photos, comparisons, bulk operations, address resolution, market reports, mortgage and affordability calculators, climate risk, and authenticated sessions. There are no obvious gaps for the stated purpose of a Redfin MCP server.
Average 4.5/5 across 21 of 21 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 122 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by specifying the return fields (sessions and active_session_id) and the null case for no sessions, providing behavioral edge-case info not covered by annotations.
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?
Two sentences, zero wasted words. The main action is front-loaded, and key details (edge case) are provided concisely.
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 no parameters and no output schema, the description covers the essential behavior and edge cases. Could briefly mention relationship to session registration/setting, but not required for completeness.
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?
No parameters exist, so schema coverage is 100%. Per guidelines, 0 params defaults to baseline 4. Description adds no parameter info (unnecessary) but is clear.
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 returns the full set of registered sessions and the current active_session_id, with explicit edge-case behavior (empty sessions and null active_session_id). It distinguishes itself from sibling tools like redfin_register_session and redfin_set_active_session by focusing on retrieval.
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 on when to use this tool versus alternatives. Does not mention prerequisites (e.g., requiring an active session) or scenarios where this is preferred over other session-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), description adds: server-side concurrency (~5 fetches), per-row error capture, output order preservation, and batch size limit. No contradictions with annotations.
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?
Six sentences, each serving a distinct purpose: purpose, output shape, error handling, concurrency, usage scenario, limitations. No redundancy, front-loaded with main action.
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?
Single parameter is fully explained; behavior (error handling, concurrency, order) and limitations are covered. Output shape is referenced to another tool, which is acceptable. No output schema, but sufficient for a bulk fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already covers parameter fully (with description). Description restates batch limit and adds error handling context but no new semantic constraints beyond schema. Baseline 3 as schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Fetch' and resource 'climate risk for up to 100 property URLs'. It differentiates from sibling `redfin_get_climate_risk` by specifying bulk nature and output shape consistency.
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?
Description explicitly says 'Use this when batching ~60-property workflows where climate risk is the dominant cost.' It also notes limitations from per-property tool apply, guiding when not to use. Could be more explicit about single-query alternatives but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds that it returns nearby active rental listings with specific fields, giving good transparency. No contradictions.
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 concise (3-4 sentences), front-loaded with purpose, and every sentence adds value. No fluff.
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 tool with 5 params and no output schema, the description explains inputs, outputs, and typical use. It could mention result limits or pagination, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 40% with descriptions on two parameters. The description mentions the parameter group (rent estimate range, lat/lng, propertyId) but adds little beyond the schema. It does not compensate for undocumented parameters.
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 finds nearby rental comparables, specifies the output fields, and distinguishes from sibling tools like redfin_get_property and redfin_search_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?
It provides context on when to use the tool (estimating rent, finding rentals) and mentions inputs are typically from redfin_get_property, but does not explicitly exclude alternative tools or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by specifying the data source (HTML page), authentication requirement ('Requires the user to be signed in'), edge case handling (empty array), and reinforcing read-only safety. Annotations already mark it as readOnlyHint, openWorldHint, and idempotentHint, so the description enriches with non-redundant context.
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 concise with four sentences, each adding unique information: what it does, structure of entries, requirement, edge case, and safety. No redundancy or wasted words.
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?
Considering there are no parameters and no output schema, the description covers the tool's purpose, required authentication, edge case, and safety. It could optionally detail the output format more, but the provided structure is sufficient for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the input schema, and schema description coverage is 100% (trivial). The description does not need to add parameter details, and it doesn't. Baseline for zero parameters is 4, and the description adequately explains the tool's inputs implicitly.
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 retrieves the signed-in user's saved searches from redfin.com, specifying the data source (saved-searches page HTML) and the structure of each entry (url, region_segment, display_text). This distinguishes it from siblings like redfin_get_saved_homes, which retrieves saved homes.
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 mentions that the user must be signed in and that an empty array is returned if none exist. However, it does not provide explicit guidance on when to use this tool versus alternatives like redfin_get_saved_homes or other search-related tools, leaving the agent to infer from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only, idempotent, open-world. The description reinforces this with 'safe to call repeatedly' and describes the output structure (date, event, price, days-on-market, source) plus tax history, adding useful behavioral context beyond annotations.
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?
Four sentences, front-loaded with purpose, no redundancy. Every sentence adds value: what data is returned, input options, read-only safety.
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?
No output schema, but description adequately explains return values (date, event, price, days, source, tax history). Missing details on conflict resolution (e.g., if both url and property_id supplied) but sufficient for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 3 parameters but only url has a description (33% coverage). The description compensates by explaining the logical grouping: 'Provide either url or property_id+listing_id,' which adds critical usage semantics not in 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 retrieves 'listing-price events for a property' and details the contents of each entry. It distinguishes from siblings by specifying the unique data (price history, tax history) and input methods (url or property_id+listing_id).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit input guidance: 'Provide either url or property_id+listing_id.' Also states 'Read-only; safe to call repeatedly.' While it doesn't compare to all alternatives, the context is clear enough for selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by detailing output order preservation, unresolved entry behavior ('resolved: false'), distinct retryable statuses (timeout/bridge_down/pending), per-row retry-once-on-timeout, server-side concurrency ~6, and a hard deadline. This provides rich behavioral context that annotations alone (readOnlyHint, openWorldHint, idempotentHint) do not cover.
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 the main purpose and then details in a logical order. Every sentence adds value, but it is slightly longer than necessary. However, the additional detail on error handling and use case justifies the length, making it well-structured and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, no output schema, and annotations covering idempotency and read-only, the description is fully self-contained. It explains input format, output behavior, error handling, retry logic, concurrency, and use cases, leaving no gaps for an AI agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a clear description of the 'addresses' parameter as an array of strings or objects. The description adds minimal extra meaning beyond restating the schema, so it meets the baseline for high schema coverage without significantly enhancing parameter understanding.
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 purpose: bulk-resolve street addresses to Redfin URLs and home_ids. It distinguishes from siblings by noting it collapses multiple search calls into one trip, and the title includes 'Bulk-resolve' which differentiates it from single-address tools like redfin_get_by_address.
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 explicitly says 'Use this when you have a list of properties from another system... and need their Redfin handles for follow-on calls.' It also contrasts with the typical multi-call flow. However, it does not explicitly state when not to use it or name alternatives, though the context implies it's for batch processing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint) cover safety; description adds context on aggregation and per-URL transparency. No contradictions. Slightly more detail on return format would push to 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose and usage. Every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple tool with one fully described parameter, no output schema, and clear annotations. Description explains return values and usage context adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already fully describes the single parameter (sample_urls: array of 2-10 URLs). Description reinforces but adds no new details beyond what schema provides. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool fetches climate risk for representative URLs and returns averaged baseline values with cluster_id. Distinguishes from sibling tools like redfin_get_climate_risk (per-property) and redfin_get_climate_risk_bulk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this before fanning out per-property calls to avoid redundant fetches if cluster agrees. Also mentions limitations (no landslide coverage). Clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description reinforces 'Read-only; safe to call repeatedly.' It adds behavioral context by explaining the URL resolve step and the possibility of count=0 for off-market listings, providing transparency beyond the annotations.
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 extremely concise, using two efficient sentences to convey all essential information. It front-loads the purpose and then details parameters and return structure without unnecessary words, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the absence of an output schema, the description fully explains the return format ({ property_id, listing_id, count, photos }) and mentions the content of each photo entry (multiple sizes, thumbnail, caption). It also covers edge cases (count=0) and security (read-only). This is complete for the tool's 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?
Although schema coverage is 100%, the description adds meaningful context by explaining the logical grouping of parameters: 'Provide either url or property_id+listing_id' and clarifying the resolve step. This enhances understanding beyond the individual parameter descriptions.
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 retrieves the full photo gallery for a Redfin property, specifying the return values (CDN URLs at multiple sizes, thumbnail, caption) and distinguishing it from sibling tools like redfin_get_property that return property details. The verb 'get' and noun 'photo gallery' are 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs how to specify the property (via url or property_id+listing_id) and notes that off-market listings may return count=0. It includes a read-only note indicating safe repeated calls. While alternatives are not explicitly listed, the context makes it clear when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds context by listing returned fields and stating 'Read-only; safe to call repeatedly,' which aligns with annotations and provides a bit more clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a purpose: what it does, what it returns, and behavior. Front-loaded with the main purpose. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description adequately covers return values (address, price, beds/baths, status) and authentication requirements. For a simple parameterless read tool, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds no param info, but nothing is needed. Baseline 4 is appropriate for zero-parameter tools.
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 returns 'the signed-in user's favorited homes on redfin.com', specifying the verb (get), resource (saved homes), and scope. This distinguishes it from siblings like redfin_search_properties or redfin_get_property.
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?
Explicitly requires the user to be signed in, giving clear context. It doesn't mention when not to use it or provide alternatives, but the name and sibling list make it obvious that this is for saved homes only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and readOnlyHint=false. The description adds that this tool sets the default routing for subsequent calls, providing useful behavioral context beyond the annotations.
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 with no wasted words. The main purpose is stated first, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description explains its purpose, how to use it, and its interaction with other tools. It is fully complete.
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 coverage is 100% and the description adds the crucial context that session_id must be previously returned by redfin_register_session, which the schema's description does not provide.
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 verb 'Switch' and the resource 'active session'. It distinguishes itself from sibling tools like redfin_register_session (creates a session) and redfin_get_session_context (gets context).
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 specifies that the session_id must come from redfin_register_session and notes that explicit session_id parameters override the default. It provides clear context but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint. The description adds detailed behavioral context: concurrency (~6 in flight), retry-once-on-timeout, overall hard deadline, pending status for slow rows, per-target error handling. No contradictions.
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 a single paragraph that is front-loaded with the main purpose. It is dense but every sentence adds value. Could be slightly more structured, but remains clear and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return shape (same as `redfin_get_property` without summary). It covers batch behavior, concurrency, timeout, error handling. For a complex batch tool, this is very complete.
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 coverage is 100%, so baseline is 3. The description adds operational context about the three target forms (url, property_id, property_id+listing_id) and the resolution process, which goes beyond the schema descriptions.
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 up to 200 Redfin property records and distinguishes it from siblings like `redfin_get_property` and `redfin_compare_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 description says 'Use this when you have a list of saved homes / candidate properties and need the full structured data for every one of them.' It also mentions an alternative tool for summary tables. However, it does not explicitly list when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it uses canonical 'realty-core' engine, is pure local math with no network, and outputs constraint breakdown. Adds behavioral context beyond annotations (idempotentHint, readOnlyHint) without contradiction.
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?
Four well-structured sentences front-load purpose, list inputs/outputs, and add engine/network context. No redundant or 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 10 params and no output schema, description provides solid coverage of inputs and expected outputs. Could detail output format more, but mentions price, constraint, and PITI breakdown sufficiently.
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?
With 0% schema descriptions, description lists most inputs (income, debts, down payment, rate, tax, insurance, HOA, loan term). Omits front_end_dti/back_end_dti but references 28/36 rule, implying defaults. Adds meaning beyond raw property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it solves for max affordable home price using 28/36 DTI rule. Distinguishes from sibling redfin_calculate_mortgage (monthly payment vs price) and search tools. Uses specific verb 'Solve for' and specifies resource 'max home price'.
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?
Describes use case for affordability based on income/debts, implying for given-price payment calculations use mortgage tool. No explicit when-not-to-use or alternatives list, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds value beyond annotations (readOnlyHint, idempotentHint) by explaining no network call, deterministic behavior, and PMI applicability. No contradiction.
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?
Four focused sentences, each providing essential information. Front-loaded with purpose, no fluff.
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?
Covers all key behaviors and parameters despite 10 parameters and no output schema. Could mention default loan term, but schema already provides default.
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 coverage is 40%, but description clarifies relationships (down_payment vs. percent, property tax options, PMI condition). Compensates well for missing schema descriptions.
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?
Clearly states it is a local mortgage calculator returning a full PITI breakdown. Distinct from all sibling tools, which focus on property searches, market reports, etc.
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?
Explicitly notes it is deterministic and safe for scenario comparison without network calls. Does not state when to avoid use, but context is sufficient for selection as the only mortgage tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, openWorldHint, idempotentHint. The description adds significant context: the 3-rung resolution ladder, matched_via values, graceful degradation with resolved: false, address discrepancy conflicts via address_alternates field, and that no auth is required. No contradictions.
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 well-structured paragraph that front-loads the main purpose, then details the algorithm, edge cases, and usage guidance. Every sentence adds essential information without redundancy. It is concise yet comprehensive.
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?
The description covers the resolution algorithm, return values (URL, home_id, matched_via, address_alternates), graceful degradation, and when to use. No output schema exists, so mentioning key return fields is helpful. It could be slightly stronger by fully specifying the output structure, but overall it is complete for the tool's 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?
Schema description coverage is 100%, so baseline 3. The description adds value by clarifying that city/state/zip are optional, explaining their role in the search fallback step, and calling the address 'free-text'. This helps the agent understand parameter optionality and fallback behavior 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 specifies the verb 'Resolve' and the resource 'address', and explains the outcome: canonical URL and home_id. It distinguishes from siblings like redfin_resolve_addresses by focusing on a single address resolution with a detailed algorithm.
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 explicitly states when to use: 'Use this when you have a property address and need its Redfin home_id for follow-on calls.' It also mentions read-only nature and no auth. However, it does not explicitly contrast with alternatives like redfin_resolve_addresses for bulk, though the singular vs plural hints at it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds valuable behavioral context: lot_size/lot_size_acres are null for condos, raw description is omitted by default to save context, and extracted_features always carries structured signals. It also explains internal resolution mechanisms. No contradictions.
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 front-loaded with the purpose, then efficiently enumerates parameter options, return fields, and nullable notes. Every sentence adds value without wasted words. It is long but appropriately detailed for a complex tool.
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 no output schema, the description adequately lists returned fields including derived ones. It explains optional includes and null behavior. However, it does not detail the structure of nested objects like extracted_features or events_normalized, leaving some ambiguity for agents needing to parse those fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds extra meaning beyond the schema: for url, it states resolution via initialInfo endpoint; for property_id, it explains the redirect; for include_description, it notes that extracted_features is the structured alternative. This adds value but not overwhelmingly beyond the already descriptive 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 opens with 'Fetch a property's full Redfin record,' which is a specific verb+resource combination. It distinguishes from siblings by noting that this tool returns a comprehensive set of fields and offers optional includes for price/tax history, contrasting with tools like redfin_get_price_history which focus solely on price history.
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 provides explicit guidance on when to use each parameter combination (url, property_id alone, property_id+listing_id) and explains the resolution process and performance trade-offs. It states the tool is read-only and safe to call repeatedly. However, it lacks explicit exclusions such as 'if you only need price history, consider redfin_get_price_history instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it states that re-registering updates rather than duplicates, and explains the default active session behavior. Although annotations include 'idempotentHint: true', the description clarifies the update semantics. No contradictions with annotations.
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 four sentences, each serving a purpose: registration action, update behavior, return value, and active session handling. It is front-loaded with the key verb and resource, and no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the absence of an output schema, the description covers all necessary aspects: registration/refresh mechanism, session identity, active session management, and return value. It is fully adequate for an AI agent to use correctly.
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 coverage is 100%, but the description significantly adds meaning: it explains that 'account_identity' is the key for session identity, clarifies the effect of re-registration, and describes how 'mark_active' works. It also explains the return value 'session_id' which is not in 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 that the tool registers or refreshes an authenticated Redfin session, using specific verbs and resource identification. It distinguishes itself from sibling tools like 'set_active_session' and 'get_session_context' by focusing on session creation/update and identity keying.
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 provides clear context on when to use: for registering or refreshing sessions to route per-tool calls. It explains the behavior of re-registering and setting active session, but does not explicitly state when not to use or directly compare to the sibling 'set_active_session' tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, openWorldHint), the description reveals the exact output structure for each metric, warns about empty data for neighborhoods, and confirms safety for repeated calls. This provides comprehensive behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first enumerates returned metrics, second explains parameter options, third details output format. No extraneous content, front-loaded with purpose, and logically ordered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (0 required), 100% schema coverage, no output schema, and straightforward return type, the description covers all necessary aspects: what the tool returns, how to invoke it with both region identification methods, and output format. No gaps identified.
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 coverage is 100%, but the description adds practical guidance: location free-text with autocomplete, recommendation to use city names, warning about neighborhoods, and default for property_type. These enrich understanding beyond basic schema types.
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 returns a market report for a Redfin region with specific metrics: median prices, $/sqft, sale-to-list ratio, homes for sale/sold, and year-over-year/month-over-month changes. It distinguishes from sibling tools like redfin_search_properties or redfin_get_property by focusing on aggregated market data rather than 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 description provides two ways to specify the region (location free-text or region_id+region_type), notes that neighborhoods often return empty data, and mentions the default property_type. It does not explicitly state when not to use this tool (e.g., for single property queries), but the context of being a market report heavily implies that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses source (Redfin HTML, no API), response shape (including `available: false` reasons), and performance tips (cluster_id grouping). Annotations already indicate read-only and idempotent, and description adds valuable behavioral context beyond annotations.
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?
Well-organized with clear sections (covered risks, exclusions, response shape, source). Some redundancy (e.g., 'DOES NOT COVER' appears twice), but overall efficient and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description fully explains response structure, error reasons, and data source. Covers all necessary context for an agent to invoke correctly and interpret results.
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 already describes the url parameter with 100% coverage. The description adds context about accepted formats (full URL or path) and examples, but the schema is already sufficient; slight extra value.
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 retrieves First Street Foundation climate risk scores for a property, listing covered risk types (flood, fire, heat) and explicitly excluding landslide, which distinguishes it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use for climate risk, excludes landslide (referencing alternatives), and suggests leveraging cluster_id to avoid redundant fetches. Also explains how to construct the URL.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds value beyond annotations by specifying the exact URL tested, the diagnostic fields (role, port, version, elapsed time, hint), and the three failure modes the hint distinguishes. It also confirms read-only and no auth, consistent with annotations.
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: first describes action and output, second gives usage guidance and properties. Every sentence is essential, no redundancy. Front-loaded with key action 'Round-trips a small public Redfin URL'.
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 no parameters and no output schema but rich annotations, the description provides sufficient detail about return values (role, port, version, elapsed time, hint) and usage context. It could specify if the output is JSON or text, but the agent can infer from the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema coverage is 100%. The description does not need to add parameter semantics, and it implicitly describes what the tool does without parameters. Baseline for 0-param tools is 4, which is satisfied.
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 title 'Verify the fetchproxy bridge end-to-end' and description clearly state the tool rounds-trips a public Redfin URL and returns diagnostics. The verb 'Round-trips' and resource 'fetchproxy bridge' are specific. It is distinct from all sibling tools, which focus on property data, sessions, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call: 'when a real Redfin tool times out and you want to know which hop failed.' It also implies not to use for normal operations. No alternative diagnostic tool exists among siblings, so no need to name an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses location resolution via autocomplete and gis API, the short-circuit behavior for addresses, the coverage field, result_cap_hit, ZIP error handling, and explicitly states 'Read-only; safe to call repeatedly.' No contradictions with annotations.
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 six sentences, each providing unique value. It front-loads the main purpose and progressively adds detail. Minor redundancy (e.g., 'Search Redfin listings' in title and description) could be trimmed, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description covers return fields, edge cases (cap hit, ZIP error, status limitation, coverage scenarios), and read-only safety. It is comprehensive for the tool's 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?
Schema description coverage is 50%; the description does not explicitly detail each parameter but mentions 'optional filters' and references price/beds filters for narrowing cap hits. It adds meaning by explaining the location parameter's resolution behavior and the status limitation. However, it could individually describe price_min/max, beds_min, baths_min to fully compensate for the missing schema descriptions.
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 purpose: 'Search Redfin listings by location... and optional filters.' It specifies the verb (Search), resource (Redfin listings), and provides differentiation from siblings by noting location resolution via autocomplete and gis API, and that full addresses short-circuit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance, including when to use a full street address (short-circuits, returns single home), when to narrow filters (result_cap_hit signals ~350 cap), and limitations (v0.1.0 supports for_sale only, ZIP fallback errors). It implicitly differentiates from alternatives like redfin_get_by_address for profile_only coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, openWorldHint, idempotentHint. Description adds concurrency, per-row error handling, omission of raw marketing description by default, and duplication weight warning for summary. No contradictions.
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?
Description is comprehensive but slightly long; every sentence is informative. Front-loaded with core purpose. Could be trimmed slightly but remains clear and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description lists return fields (price, beds/baths, sqft, etc.) and notes extracted_features always included. Covers input, output, error handling, concurrency, and optional fields. Complete for agent decision-making.
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 coverage is 100%, yet description adds value: targets array min/max items and alternative tool reference, include_summary's duplication weight, include_description's context-saving purpose. Each parameter's behavior is enhanced beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'fetch and compare 2 to 25 Redfin properties side-by-side' with specific input format (url or property_id+listing_id) and output fields (price, beds/baths, etc.). It distinguishes from sibling redfin_bulk_get, which handles larger batches or non-comparison workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use redfin_bulk_get instead ('>25 properties or workflows that don't need side-by-side analysis'). Clarifies when to use include_summary and include_description, including context-saving considerations.
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:

[![redfin-mcp MCP server](https://glama.ai/mcp/servers/chrischall/redfin-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrischall/redfin-mcp)

Score Badge

Copy to your README.md:

[![redfin-mcp MCP server](https://glama.ai/mcp/servers/chrischall/redfin-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/redfin-mcp)

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/chrischall/redfin-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server