Skip to main content
Glama
chrischall

homes-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get a homes.com market report for a location

homes_get_market_report
Read-onlyIdempotent

Fetch recently sold homes for a city, ZIP, or neighborhood and get a sample-based market summary with sale count, median sale price, and average price per square foot.

Instructions

Fetch homes.com's recently-sold listings for a city/ZIP/neighborhood and derive a market summary: count, median sale price, and average $/sqft across the sample. Pass location — free-text (e.g. 'Brooklyn, NY', '30311'). location is required and must contain Latin letters or digits — a blank or unsluggable location (e.g. only punctuation or non-Latin script) is rejected with an error rather than returning an empty result. Returns { region, slug, sold_summary, sample_sold }. Note: homes.com's sold page typically returns ~40 recent listings — this is a sample-based summary, not an exhaustive market index. Read-only.

Input Schema

NameRequiredDescriptionDefault
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact strips image/avatar URLs from the response; "full" returns Homes.com's payload untouched. No field projection: this server has no verified record of which Homes.com fields matter, and inventing one would risk dropping a field a caller needs.
locationYesFree-text location: city, ZIP, neighborhood

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.1.11
    • addedInput schema / properties / location / minLength
      Added value: +1
  2. Changed1 schema field changedv2.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Changed1 schema field changedv1.4.1
    • addedInput schema / properties / view
      Added value: +{
+  "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact strips image/avatar URLs from the response; \"full\" returns Homes.com's payload untouched. No field projection: this server has no verified record of which Homes.com fields matter, and inventing one would risk dropping a field a caller needs.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  4. First observedv1.1.1

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly/idempotent/openWorld, but the description adds substantive behavioral context: the ~40-listing sample cap, that it is a sample not an index, and that an invalid location errors out rather than returning empty. This is exactly the kind of limitation an agent needs to avoid misusing results.

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?

Front-loaded with the action and derived outputs, then parameter rules, then return shape and a caveat. Dense but each sentence carries information; a minor trim of the parenthetical e.g. list is possible but harmless.

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?

No output schema exists, and the description compensates by naming the returned keys ({ region, slug, sold_summary, sample_sold }) and warning that the summary is sample-based. Together with full schema coverage on inputs, an agent has everything needed to call and interpret it.

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 the baseline is 3, but the description adds meaning beyond the schema: concrete location examples and the Latin-letter/digit validation rule that explains what 'unsluggable' means and why a blank input fails. The view parameter is left entirely to the schema, which is acceptable.

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?

States a specific verb (fetch + derive) and resource (homes.com recently-sold listings → market summary) and enumerates the derived metrics (count, median sale price, avg $/sqft). This clearly distinguishes it from siblings like homes_search_properties and homes_get_property_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?

Explains that this returns a sample-based market summary rather than an exhaustive index, which tells the agent when this is the right tool. It does not explicitly name an alternative for exhaustive market data, so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools