Homesage.ai MCP

Advanced Renovation Cost Breakdown

advanced_renovation_cost_breakdown

Read-only

What it returns

An itemized room-by-room renovation cost breakdown powered by a multimodal LLM analyzing the property's images plus its size/feature metadata. Returns per-room scope, material/labor split, and total cost — significantly more detailed than the top-level renovation-cost aggregate.

When to use it

Generate detailed scope-of-work documents from photos.
Underwrite specific renovation strategies.
Show investor clients exactly where the money goes.

Pricing

5 credits.

Request

Provide ONE input mode:

property_id — we pull the listing images and metadata for it.
property_address — we resolve the property server-side.
Your own photos — the full property object (address, total_sqft, bedrooms, bathrooms) plus an images array of URLs, or a multipart/form-data upload with repeated images file fields (JPEG/PNG/WebP) alongside property_id/property_address.

At most 30 images are analyzed per request; extras are ignored. Analyses of your own photos are private: they always run fresh, are never served from or written to the shared per-property cache, and never change the property's stored condition.

FAQ

Can I send my own photos?

Yes, two ways: a JSON images array of http(s) URLs, or a multipart/form-data upload with repeated images file fields (JPEG/PNG/WebP). Pair them with the property object (or property_id/property_address). At most 30 images are analyzed per request; extras are ignored. Your photos stay private — the analysis always runs fresh and never touches the shared per-property cache or the property's stored condition.

Can I force a fresh LLM analysis (bypass cache)?

Yes — set force_refresh: true in the request body. Bypasses the per-property cache.

What LLM is used?

A multimodal model tuned for construction-cost estimation. Outputs are in domain terms (rooms, materials, line-items) and stable across model swaps.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "advanced_renovation_cost_breakdown"
  }
}

Input Schema

Name	Required	Description
`images`	No	Your own photo URLs (http/https), up to 30 — extras beyond 30 are ignored. Supplying your own images makes the analysis private: it always runs fresh on your photos, is never served from or written to the shared per-property cache, and never updates the property's stored condition.
`property`	No	Property facts used when you supply your own images. Required together with `images` when neither `property_id` nor `property_address` is sent.
`property_id`	No	Homesage property id (returned by search and property-info endpoints). The backend pulls the listing images and metadata for it.
`force_refresh`	No	Set true to bypass the 30-day per-property response cache and force a fresh AI analysis. Only meaningful with property_id / property_address (custom-image requests always run fresh).
`property_address`	No	Full US property address; the backend resolves the property, its listing images, and metadata server-side.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Well beyond the readOnly/openWorld annotations, it discloses the 5-credit price, the 30-image hard cap with extras silently ignored, a 30-day per-property response cache with a `force_refresh` bypass, and a clear privacy contract for custom photos (fresh run, no cache read/write, no change to stored condition). It also sets expectations that outputs are in domain terms and stable across model swaps.

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?

The header structure and front-loading of return value are good, but the FAQ largely duplicates the Request section near-verbatim — the 30-image cap, privacy guarantee, and cache behavior are each restated twice. Those repeated sentences do not earn their place in an already long description.

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 5-parameter tool with a nested `property` object and an existing output schema, the description covers what an agent needs to invoke it correctly: input-mode choice, image formats and limits, multipart alternative, cost, and caching behavior. Return values are left to the output schema, which is the right division of labor.

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 already 100%, so the baseline is 3; the description earns more by stating the exclusivity rule (supply ONE input mode: property_id, property_address, or property+images) and documenting a `multipart/form-data` upload path that exists nowhere in the schema. It also clarifies that `force_refresh` is only meaningful for property-id/address requests.

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 a specific verb+resource ("itemized room-by-room renovation cost breakdown") and states the mechanism (multimodal LLM over images plus size/feature metadata). It explicitly differentiates from the sibling `renovation-cost` aggregate by calling this "significantly more detailed," so an agent can choose between them without opening the schema.

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 "When to use it" section gives three concrete scenarios (scope-of-work docs, underwriting specific strategies, investor-facing line items) and the contrast with the top-level aggregate implies when to prefer the cheaper sibling. It stops short of an explicit exclusion or guidance on when the simpler tool suffices for cost reasons.

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

All Homesage.ai MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?