pricewise-mcp

Overview Schema Source Related Servers Discussions Admin

Estimate price range (synthetic demo)

estimate_price_range

Read-onlyIdempotent

Estimate a used car's asking price range from body category, age and kilometres; get calibrated 50% and 80% ranges from synthetic demo data.

Instructions

Demo of calibrated price ranges: estimate a used car's asking price from its body category, age and kilometres, with a range half of similar cars fall in (range_50) and one eight in ten fall in (range_80).

The model is trained on SYNTHETIC, made-up listings. Never present the result as the value of a real car or use it for a purchase or sale decision: say it comes from a synthetic demo market, and relay flags.

The first call after the server starts can take up to about 20 seconds while the model is fitted.

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": {
      "category": "<category>",
      "age_years": "<age_years>",
      "usage": "<usage>"
    },
    "name": "estimate_price_range"
  }
}

Input Schema

Name	Required	Description
`usage`	Yes	Odometer reading in km (not miles).
`category`	Yes	Body category. Pick the closest: an SUV is 'crossover', a small city car is 'hatchback', a station wagon ('carrinha') is 'estate', any battery-electric car is 'electric'.
`age_years`	Yes	Age of the item in years.
`condition`	No	Condition, if known. Omit when unknown (many listings omit it).

Output Schema

Name	Required	Description	Default
`flags`	Yes	Caveats to relay, including extrapolation warnings.
`notice`	No		Trained on synthetic, made-up listings. Prices and ranges say nothing about any real market; they show how the method behaves.
`range_50`	Yes	Half of similar items land inside this range.
`range_80`	Yes	Eight in ten similar items land inside this range.
`point_eur`	Yes	Best single estimate, in euros.
`data_source`	No		synthetic
`comparables_median_eur`	Yes	Median price of similar items in the synthetic pool (same category, age within a year, usage within 20%); null if fewer than 3 are similar.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial non-obvious behavior: the model is trained on synthetic listings, the output includes a `flags` field that must be relayed, and the first call after server start can take ~20 seconds while the model is fitted. The cold-start latency warning is exactly the kind of operational detail annotations cannot express.

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 purpose, then caveats, then the latency note — a sensible ordering with no filler sentences. Minor redundancy: the range_50/range_80 explanation restates what the output schema already provides, and the phrasing "one eight in ten fall in" is slightly awkward.

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 an output schema present, the description need not detail return values, and it covers everything else an agent needs: the synthetic-data constraint, the mandatory disclosure and flags relay, and the cold-start latency. Nothing required for a correct call or a correct presentation of the result 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?

Schema description coverage is 100%, so the schema already defines category, age_years, usage (km, not miles), and the optional condition. The description restates the input dimensions but adds no meaning beyond the schema, and it never mentions the optional `condition` parameter at all. Baseline 3 is appropriate where the schema does the heavy lifting.

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?

States a specific verb and resource plus the inputs that drive it: "estimate a used car's asking price from its body category, age and kilometres." The output semantics (range_50, range_80) are named explicitly. It does not reference the sibling calculators (calculate_isv, calculate_iuc), so differentiation is left to domain inference rather than stated.

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?

Gives an explicit when-not-to-use rule: never present the result as a real car's value or use it for a purchase/sale decision, and always disclose the synthetic demo market and relay `flags`. That is clear context plus an exclusion. However, no alternative tool or fallback is named for cases where a real valuation is needed.

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

Deploy Server