Homesage.ai MCP

Get Price Flexibility Score

get_price_flexibility_score

Read-only

What it returns

A Price Flexibility Score (PFS) for an active listing — an estimate of how much price-negotiation room it has, derived from days-on-market, price-change history, comparable activity, and seasonal demand. Higher score = more flexible (buyer can negotiate down more).

When to use it

Suggest a target offer percentage to a buyer.
Sort lead lists by negotiation opportunity.
Trigger an alert when a watched property's PFS climbs.

Pricing

2 credits.

FAQ

Does PFS work on sold properties?

PFS scores a live asking price, so it returns a 400 error ({"error": "Property is sold"}) only when the property's current listing status is exactly sold. A recently-sold property whose status is anything else (for_sale, off_market, pending, ...) still returns a normal score — so a property can show up in sold-by-zip results and still be scorable here.

Is PFS the same as AVM?

No. AVM estimates what the property is worth. PFS estimates how movable the asking price is — orthogonal questions.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "property_address": "<property_address>"
    },
    "name": "get_price_flexibility_score"
  }
}

Input Schema

Name	Required	Description	Default
`property_address`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, and the description adds substantive context beyond them: the cost (2 credits), the exact failure mode (400 with {"error": "Property is sold"}), and the non-obvious caveat that only a status of exactly `sold` triggers it, so a property appearing in sold-by-zip results may still be scorable. That status edge case is the kind of behavior an agent cannot infer from structured fields.

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?

Markdown headings front-load the return value before usage and edge cases, and each section is short. The pricing line and FAQ are justified rather than filler, though the FAQ heading for a single question is slightly heavy scaffolding for the content it carries.

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 single-parameter read-only scoring endpoint with an output schema, this covers everything an agent needs: what the number means, its direction (higher = more flexible), cost, and the one error path. Return-value detail is handled by the output schema, so nothing material is missing.

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?

There is a single required parameter with 0% schema description coverage, and the description says nothing about what form the address must take or how strictly it is matched. The parameter name is self-describing and the schema supplies a full formatted example, so an agent is unlikely to fail, but the description contributes no meaning over 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?

Names a specific named metric (Price Flexibility Score) and defines it precisely: 'an estimate of how much price-negotiation room it has, derived from days-on-market, price-change history, comparable activity, and seasonal demand.' The FAQ explicitly contrasts it with the AVM sibling (get_current_estimate), so an agent can separate it from look-alike valuation tools without opening either 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?

A dedicated 'When to use it' block gives three concrete scenarios (target offer suggestion, sorting leads by negotiation opportunity, alerting on PFS changes). The AVM contrast adds implicit alternative-routing. It lacks any explicit 'do not use when' statement, so it stops short of full exclusion guidance.

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?