homes-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: v1.1.3
Disambiguation5/5
Every tool has a clearly distinct purpose. Search, property details, calculators, session management, and bulk operations are all separate and non-overlapping. Even deprecated tools are explicitly replaced.
Naming Consistency4/5
Most tools follow a consistent 'homes_verb_noun' pattern. Minor deviations like 'homes_healthcheck' and 'homes_estimate_rent_vs_buy' break the pattern slightly, but the overall convention is clear and predictable.
Tool Count4/5
At 21 tools, the set is slightly large but well-justified for a real estate platform covering search, details, comparisons, calculators, session management, and bulk operations. No tools feel redundant or unnecessary.
Completeness4/5
The tool surface covers core real estate workflows: search, property details, history, photos, comparisons, calculators, address resolution, and session management. Minor gaps exist (e.g., no rental estimates), but overall it's comprehensive for a consumer search MCP.
Average 4.5/5 across 21 of 21 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 123 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

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds that it is pure local math with no network dependency and describes the output (max home price, binding constraint, PITI breakdown). 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 of three sentences, front-loaded with purpose. Nearly every sentence adds value, but a more structured listing of inputs and outputs would improve clarity.
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?
Given 10 parameters, no output schema, and sparse annotations, the description covers inputs and outputs but lacks details on defaults, edge cases, or precise DTI ratio specification (just 'standard 28/36'). Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description lists several input parameters but does not explain their meaning or constraints (e.g., what front_end_dti and back_end_dti represent). It adds some context but insufficient for 10 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 the tool solves for maximum affordable home price using standard 28/36 DTI rule, lists inputs and outputs, and distinguishes from siblings by noting identical math to zillow-mcp and redfin-mcp.
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 for affordability calculation but does not explicitly state when to use it over the sibling tool homes_calculate_mortgage or what alternatives exist within the suite. It mentions identical math externally but no internal differentiation.
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, idempotentHint, openWorldHint. The description adds deprecation status, planned removal, and data shape (tax paid, assessed value, land/improvement split). 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 relatively short and front-loaded with DEPRECATED. It conveys deprecation, alternatives, and data shape efficiently, though the deprecation notice takes up significant space.
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 1-param tool with no output schema, the description adequately explains the return data (tax records with fields). It lacks error case info but is otherwise complete given the straightforward nature.
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?
Only one parameter (url) with full schema description coverage. The description does not add additional meaning beyond 'homes.com property detail URL or path' already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns property tax records (tax paid, assessed value, land/improvement split) but the deprecation notice is primary. It distinguishes from siblings by naming alternatives, but the core function is slightly overshadowed.
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 says to prefer homes_get_history or homes_get_property with include_tax_history, providing clear when-to-use guidance and naming the alternative 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?
Description adds response structure details and cross-MCP normalization beyond annotations. States read-only and safe to call repeatedly, 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?
Five sentences, front-loaded with purpose, efficient in conveying all necessary information without 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?
Adequately describes response structure and empty series behavior. No output schema, but description covers key aspects for a simple read 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?
Single parameter with 100% schema coverage. Description only restates schema ('full property detail URL'), adding minimal extra meaning.
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 combined endpoint replacing two other tools. Specifies return fields and distinguishes from siblings.
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 says to pass the full property detail URL and describes behavior when series are empty. Implies preferred over individual history tools but lacks explicit when-not-to-use.
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 readOnly and idempotent. The description adds value by specifying null/empty states, which is beneficial 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?
Two sentences, front-loaded with key actions and edge cases. No unnecessary 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?
For a simple read-only tool with no parameters and annotations, the description explains return values and edge cases. Lacks detail on session object format but sufficient for 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?
No parameters, so baseline 4. Description adds no parameter info but none needed.
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 all registered sessions and the active_session_id, with edge cases explained. Distinguishes from siblings like homes_register_session and homes_set_active_session.
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 for viewing sessions but lacks explicit when-to-use or when-not-to-use guidance or comparisons with 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 adds significant value beyond annotations by noting the tool returns a sample of ~40 listings, the summary is not an exhaustive market index, and explicitly states 'Read-only'. This compensates well for the existing readOnlyHint and idempotentHint 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 concise (3 sentences) and well-structured: purpose, parameter usage, return structure, and a caveat. Every sentence adds value, and the key information is front-loaded.
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 no output schema, the description clearly outlines return fields (region, slug, sold_summary, sample_sold) and explains that sold_summary includes count, median sale price, and average $/sqft. The sample-size caveat provides essential context. Annotations complement well.
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 single parameter 'location' is fully described in the schema (100% coverage). The description provides example values but does not add new semantic or syntactic details beyond the schema description. Baseline score of 3 is appropriate.
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 'Fetch and derive', the resource 'recently-sold listings' and 'market summary', and specifies the output structure. It distinguishes itself from siblings like homes_search_properties by focusing on market summary from sold data.
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 explains how to use the tool (pass location as free-text) but does not explicitly state when to use this tool vs. alternatives like homes_search_properties or when not to use it. The context is clear but lacks exclusionary guidance.
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 the annotations (readOnlyHint, idempotentHint), the description adds key behavioral details: it is local-only, no network call, PMI applies automatically when LTV > 80% and pmi_rate is provided. No contradiction 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 long, front-loading the purpose and then succinctly covering parameter details. Every sentence serves a purpose with no 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?
Given 10 parameters, no output schema, and rich annotations, the description covers key behaviors (no network call, PITI breakdown, parameter alternatives). It could mention return format but is adequate.
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 only 40% schema description coverage, the description compensates by explaining defaults (down_payment_percent defaults to 20%), conditional PMI behavior, and alternative ways to provide property tax. This adds significant meaning 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 is a 'Local-only mortgage payment calculator' that returns a 'full PITI breakdown', using specific verbs and distinguishing it from the sibling tool 'homes_calculate_affordability' by focusing on detailed mortgage components.
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 (local calculation, no network call) and parameter alternatives (e.g., 'Provide either down_payment OR down_payment_percent; defaults to 20%'). It lacks an explicit when-not-to-use statement for other scenarios but is clear enough.
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, and idempotentHint, so the safety profile is known. The description adds value by detailing the returned data structures (listing_events, ownership_events, lien_events, events_normalized), going beyond annotations. No destructive behavior mentioned, consistent with readOnlyHint.
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 sentences to convey deprecation, alternatives, and output structure. No filler, every sentence earns its place. Front-loaded with the most important info.
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 deprecated tool with a single parameter and no output schema, the description is complete: it explains what data is returned and provides migration path. Could optionally mention that it only works with homes.com URLs but that is implied. Slightly more detail about the 'events_normalized' cross-MCP enum might help, but overall adequate.
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 only parameter 'url' is fully described in the schema (100% coverage). The description does not add additional semantic meaning beyond the schema's 'homes.com property detail URL or path.' Baseline 3 applies as schema covers the parameter; no extra clarification needed.
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 property history (three timelines) for a homes.com property. It immediately identifies the tool as deprecated and specifies the preferred alternatives, making the 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly marks the tool as DEPRECATED and directs users to 'homes_get_history' or 'homes_get_property' with include_price_history, providing clear when-to-use and when-not-to-use guidance. This is ideal for a deprecated 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 provide readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral details: URL scraped, return shape, DOM-scraping edge cases for name/filters, and error condition. This goes beyond what annotations provide.
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, well-structured, and front-loaded with the purpose. Every sentence adds value with no 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 zero parameters, good annotations, and no output schema, the description covers the essentials: purpose, prerequisite, return shape, and edge cases. Could optionally mention rate limits or limits on saved searches, but not necessary.
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 tool has zero parameters, so the parameter burden is minimal. The description compensates well by explaining the tool's behavior and return structure without needing param details.
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 on homes.com. It uses a specific verb ('get') and resource ('saved searches'), and distinguishes from sibling tools like homes_get_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite that the user must be signed into homes.com in their browser tab, and explains the error if not. Although it does not compare directly to siblings, the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by explaining the tool is read-only and no auth required, and details the diagnostic outputs. It aligns with readOnlyHint and idempotentHint 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 a single paragraph that is concise and front-loaded with the core action. It packs necessary detail without being verbose.
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 no parameters and no output schema, the description fully covers what it does, when to use it, and what diagnostics it returns. It is complete for its 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?
No parameters exist in the schema, so the description does not need to add param detail. Baseline score of 4 applies.
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 round-trips a URL through the fetchproxy bridge and returns diagnostics, with a specific verb and resource. It distinguishes itself from sibling tools by being the only healthcheck tool among property/search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call this when a real homes.com tool times out to diagnose which hop failed, providing clear usage context. However, it does not explicitly mention when not to use it or 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?
The description adds significant context beyond annotations: it explains idempotent update behavior (re-registering same identity updates instead of duplicate), default session assignment, and mark_active effect. Annotations already indicate idempotentHint=true and readOnlyHint=false, which are consistent. The description could further detail side effects or auth requirements but does not contradict 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 concise—four sentences, front-loaded with the primary action. Every sentence adds essential information: registration/refresh, idempotency, return value, default behavior, and mark_active option. No redundant 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?
Given the lack of output schema, the description adequately explains the return value (session_id) and key behavioral aspects. It covers registration, refresh, idempotency, and active session behavior. Minor gaps: error conditions, authentication prerequisites, or effects of auth_expires_at are not addressed, but the core functionality is well-covered.
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% with descriptions for all parameters. The description adds extra meaning: it clarifies that re-registering the same account_identity updates the session, and explains the significance of mark_active in making the session active immediately. This enriches parameter understanding beyond the schema's basic 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 registers or refreshes an authenticated Homes session, explicitly distinguishing idempotent behavior (updates rather than duplicates) from potential duplication. It differentiates from sibling session tools by explaining the role of 'mark_active' and default session behavior, making its purpose distinct.
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 for when to use the tool (registering or refreshing a session) and hints at related functionality (mark_active to set active). However, it does not explicitly exclude alternatives like 'homes_set_active_session' or mention when not to use this tool, leaving some ambiguity for agents.
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 readOnly and idempotent; description adds critical behavioral details: server-rendered cap, truncation flag, slugification, Schema.org parsing. 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?
Concise at ~150 words with clear structure: purpose, parameters, cap warning. Every sentence adds value; no 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?
Covers key aspects for a search tool: input parameters, behavior (parsing, slugification, cap), and output fields. Lacks error handling or rate limit info, but the overall completeness is high given the 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 coverage is 100%, but description adds meaningful extra context like slugification examples (e.g., 'Atlanta, GA' + condo + for_sale → /atlanta-ga/condos-for-sale/) and explains how limit and price filters interact with the cap. This goes beyond the schema's dry 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 it searches homes.com listings by free-text location with optional filters, and distinguishes from nearby sibling tools like homes_get_property by detailing the parsing and slugification behavior.
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 advises on when to use (search listings) and provides workaround for the 40-listing cap via price-banding or sub-area segmentation. Implicitly contrasts with single-property tools but doesn't name alternatives directly.
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, idempotentHint, and openWorldHint, and the description adds significant behavioral context: it scrapes every <img> tag, filters to CDN, is read-only and safe to call repeatedly, and returns a specific structure. 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 and well-structured: it opens with the purpose, then explains the scraping rationale, describes the parameter with an example, and details the return type. Every sentence adds value without redundancy.
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 fully details the return format. It addresses the single parameter, explains how to obtain the input from a sibling tool, and covers the tool's behavior. Given the low complexity and rich annotations, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'url' parameter, so the description adds only moderate guidance (e.g., passing the url from homes_search_properties result). The baseline of 3 is appropriate as the schema already documents it fully.
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 gets the 'full photo gallery for a homes.com listing' and explains why it scrapes img tags (JSON-LD only gives one image). The verb 'get' and resource 'property photo gallery' are specific, and the tool is well-distinguished from siblings like homes_search_properties or homes_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?
The description explains when to use this tool (when full gallery is needed, since JSON-LD only provides one image) and how to obtain the input url from homes_search_properties. However, it does not explicitly state when not to use it or mention 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?
The description explains the side effect: changing default routing for subsequent calls. Annotations indicate idempotent and not read-only, which aligns. It adds context beyond annotations by explaining the override behavior.
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 action, and every sentence adds value. No unnecessary 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?
For a simple tool with one parameter and no output schema, the description is complete. It explains the effect, prerequisite, and interaction with other tools. No gaps.
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 describes the parameter as 'Session id to make active.' The description adds meaning by specifying it must be 'previously returned by homes_register_session', which is not in the schema. Since schema coverage is 100%, the description provides valuable extra context.
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: 'Switch which registered session subsequent tool calls route through by default.' It uses a specific verb 'Switch' and resource 'registered session', and distinguishes from siblings by referencing 'homes_register_session'.
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: pass a session_id from homes_register_session, and notes that explicit session_id parameters override the default. It lacks explicit exclusions but is sufficient for this simple 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 (readOnly, idempotent), the description discloses that calls are concurrent, per-target errors are isolated, and summary is redundant/opt-in. This provides rich behavioral context.
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 well-structured, front-loading the purpose, then detailing input, output, and options. While long, every sentence adds value. Minor improvement could be tightening the summary explanation.
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 no output schema, the description thoroughly covers return fields (extracted_features, hoa, etc.), error handling, concurrency, and optional features. It is complete for the agent to use correctly.
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 valuable context: for 'targets' it specifies the source of URLs, for 'include_summary' it explains redundancy, and for 'include_description' it clarifies why it's default false. This goes 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 and aligns properties side-by-side. It uses a specific verb ('compare') and resource ('homes.com properties'), and distinguishes from siblings like homes_get_property and homes_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?
The description explains when to use this tool (comparing multiple properties), provides input format (URL from search results), and notes error handling (per-target errors don't fail whole call). However, it doesn't explicitly contrast with alternatives like homes_bulk_get.
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 indicate read-only, open-world, and idempotent. The description adds substantial behavioral details: three resolution rungs, matching logic, price bound scope, known failure modes, and return format. No contradiction 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 long but well-structured: purpose first, then mechanism, params, returns, and caveats. Every sentence adds value, though slightly verbose. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple rungs, fallback, price bounds), the description covers resolution flow, match confirmation, failure modes, and batch alternatives. No output schema but return format is detailed. Complete for a read-only lookup 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 coverage is 100%, so baseline is 3. The description enriches parameters by explaining price_min/max's role only in the fallback, and the optionality of zip. It adds context beyond 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 it resolves a US street address to a canonical homes.com property URL and hash, using a specific verb and resource. It distinguishes from sibling tools like homes_resolve_addresses by noting batch size preference.
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 advises using homes_resolve_addresses for batches of 3 or more addresses, and explains when price bounds are applicable. While not exhaustive on when-not-to-use, it provides clear context for invocation.
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 and idempotentHint. Description adds detailed behavioral info: fan-out process, matching criteria, per-row outcomes (failure won't fail all), result ordering, and safe-to-call nature. 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?
Well-structured with clear sections: batch size, parameter format, matching process, outcome shape, usage recommendation. Could trim some technical details but overall effective.
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 output schema, the description thoroughly explains the return object structure and fields. References sibling tools and provides usage context. Complete for an AI agent to select and invoke correctly.
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 description adds meaning beyond schema: explains matching logic, optional price bounds, and outcome field mapping (property_id vs property_hash).
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 resolves up to 100 street addresses to homes.com property URLs and opaque property hashes. It distinguishes itself from siblings by explicitly comparing to homes_get_by_address and homes_bulk_get.
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 guidance: 'Use this instead of looping homes_get_by_address for any batch ≥ 3.' Describes fan-out logic and fallbacks. Lacks explicit 'when not to use' but threshold is clear.
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 readOnly, openWorld, idempotent. Description adds significant context: results ordered to match input, per-row error handling, status field, omitted description by default, hard deadline with pending status. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is verbose and runs as a single paragraph. While informative, it could be more structured (e.g., bullet points) for easier parsing. Still front-loaded with main purpose, but dense.
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?
Comprehensive coverage of input, behavior, return fields, error handling, deadline, and comparison with alternatives. No output schema exists, so description carries full burden and does so effectively.
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. Description adds context: urls come from search results, include_description default false, and notes that urls can be paths. Provides reasonable added value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Fetch up to 200 homes.com properties in one call and return their structured records.' Clearly distinguishes from sibling tools like homes_get_property (single) and homes_compare_properties (limited to 8 with summary).
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 this instead of looping homes_compare_properties when you just want the records.' Also implies when not to use by referencing alternatives. Covers ordering, error handling, and pending behavior.
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 explains internal behavior: 'Accounts for down payment, closing costs, monthly PITI, maintenance (~1%/yr default), appreciation (~3%/yr default), rent growth (~3%/yr default), and the opportunity cost of the down payment (renter invests it at investment_return_rate, default 6%/yr).' It states 'Returns year-by-year cumulative costs, break-even year, and the net difference at horizon' and 'No network — pure local math.' These detail effects beyond annotations (readOnlyHint, idempotentHint) and do not contradict them.
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 and well-structured: two paragraphs—first explaining the tool's function and inputs, second providing a critical note about data sourcing. It front-loads the primary purpose and uses clear language. Every sentence adds value, with no repetition of schema fields.
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 15 parameters and no output schema, the description is fairly complete: it explains the model, outputs (year-by-year costs, break-even, net difference), and the need for a rent estimate. It could mention the relationship to siblings (e.g., similar to homes_calculate_mortgage but adds rent comparison) and clarify the absence of network dependency (already stated). Still, it covers the essential context for effective tool selection.
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 description coverage, the description must compensate. It does so by explaining many parameters in context: down payment, closing costs, monthly PITI, maintenance (maintenance_rate), appreciation (appreciation_rate), rent growth (rent_growth_rate), opportunity cost (investment_return_rate). However, not every parameter (e.g., hoa_monthly, insurance_annual) is explicitly named, though they are implied by 'closing costs' and 'PITI'. Overall, it adds substantial meaning 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's purpose: 'Project the cumulative cost of buying a home versus renting a comparable place over N years.' It specifies the factors considered (down payment, closing costs, PITI, maintenance, appreciation, rent growth, opportunity cost) and distinguishes from siblings like homes_calculate_mortgage by focusing on the buy-vs-rent comparison. The mention of same math contract as zillow_estimate_rent_vs_buy further aids differentiation.
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: 'NOTE: caller must supply `monthly_rent` — homes.com does not publish rental estimates...' and suggests alternative tools (zillow_get_property, redfin_get_comparable_rentals) for obtaining a rent estimate. It also indicates when not to use (if no rent estimate available) and contextualizes that this is pure local math with no network dependency.
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 read-only nature and safety for repeated calls, matching annotations. Describes the parsing process and detailed return structure, including derived fields like extracted_features. 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?
Description is front-loaded with core purpose, then details returns and optional parameters. Slightly lengthy but well-structured. Every sentence adds value; could be condensed slightly but remains clear.
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 comprehensively documents input parameters, return fields (with derived attributes), optional features with rationale, and behavioral traits. Fully adequate for an AI agent to select and invoke the tool correctly.
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% with good descriptions, but the tool description adds meaning: explains why include_description defaults false (weight), why price/tax history inlining saves round trips, and that url comes from search results. Adds value 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?
The description clearly states 'Fetch a property's full homes.com record' with a specific verb and resource. It distinguishes itself from sibling tools by explaining that it can optionally inline price/tax history data, saving round trips compared to dedicated 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?
Explicitly tells when to use: pass the url from homes_search_properties results. Provides alternatives for price/tax history via include flags, and notes that opting in costs nothing extra over dedicated tools. Clear context and exclusions.
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. The description adds context by stating 'Read-only; safe to call repeatedly' and describing the return format and limitations (no price/beds/baths), which aligns with annotations and adds value beyond them.
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 with no fluff. It front-loads the purpose, then covers parameters, return format, limitations, enrichment suggestion, and safety note—all in a concise manner.
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 no output schema, the description provides a detailed return format including structure. It covers main use, edge cases (include_rentals, limit), limitations (no price data), and relates to sibling tools. Comprehensive for a 3-param 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 coverage is 100%, so baseline is 3. The description adds value by contextualizing each parameter: url is 'the property whose neighborhood to inspect', limit caps count, and include_rentals controls tab inclusion, including default behavior. This elevates the score to 4.
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 scrapes the nearby-links section of a homes.com detail page and returns nearby active listings. It specifies the HTML element and tab behavior, and distinguishes from sibling tools like homes_get_property and homes_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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (to get nearby listings) and when not (curated cross-link list, not comparable-sales set). It suggests using homes_get_property to enrich rows and clarifies tab behavior with include_rentals.
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), the description adds significant behavioral context: it scrapes DOM, fields may be missing as best-effort, and it's 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: main action stated first, then return format, then usage notes. Every sentence adds value without redundancy.
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 no parameters and no output schema, the description fully covers all necessary information: purpose, return shape, edge cases, and linking to sibling tool. Complete for decision-making.
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 has no parameters, so the description does not need to add parameter information. Baseline of 4 for 0-parameter tools is appropriate as the description correctly avoids extraneous detail.
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/favorited homes from homes.com. It specifies the source URL and return structure, distinguishing it from sibling tools like homes_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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises calling `homes_get_property(url)` per row for canonical records, describes the prerequisite of being signed in, and notes the error when not authenticated. This provides clear guidance on when to use this tool versus alternatives.
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:

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

Score Badge

Copy to your README.md:

[![homes-mcp MCP server](https://glama.ai/mcp/servers/chrischall/homes-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/homes-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/homes-mcp'

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