Dorit

Estimate a price

estimate_price

Read-onlyIdempotent

Grounded rent or sale price estimate from Dorit's listing corpus: a headline figure with a low–high band, sample size and window, for a neighborhood or street subject (location + rooms) or for one listing (listing_id, which also says whether its asking price is above or below market). A refusal (insufficient_data, unsupported_market, unknown_location, needs_clarification) means there is no honest number — never replace it with a guess.

Input Schema

Name	Required	Description
`city`	No	City, when the location alone is ambiguous.
`floor`	No
`rooms`	No	Required with location.
`context`	Yes	Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
`location`	No	A neighborhood, a street, or "street, city" — as the user named it.
`amenities`	No	Only amenities the user stated; an omitted one neither raises nor lowers the estimate.
`condition`	No
`llm_model`	Yes	The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
`listing_id`	No	Price a specific Dorit listing against its market. When set, send no other field.
`property_type`	No	Sale only: apartment, unit, garden, house, twofamily, penthouse, duplex.
`square_meters`	No
`transaction_type`	No	Defaults to rent. Sale estimates run in fewer cities and also return registered sold deals for a street subject.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 25, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / context

Added value: +{
+  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
+  "type": "string"
+}

addedInput schema / properties / llm_model

Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}

addedInput schema / required

Added value: +[
+  "context",
+  "llm_model"
+]

First observedOct 16, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only cover safety (readOnly, idempotent, non-destructive, closed-world); the description adds the substantive behavior an agent cannot get elsewhere — the returned shape (headline figure, band, sample size, window) and the meaning of each refusal (insufficient_data, unsupported_market, unknown_location, needs_clarification) with a hard rule not to fabricate a number. That is exactly the kind of context annotations cannot convey.

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?

Two sentences, front-loaded with the outcome and return shape before the refusal contract. It is dense with stacked parentheticals, so a scan requires careful reading, but essentially no clause is filler.

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 12-parameter tool with no output schema, the description supplies the return contract and refusal taxonomy, which is the hardest part to infer. The analytics-only parameters (context, llm_model) and the amenity-neutrality rule are documented in the schema rather than the description, which is acceptable but leaves the definition slightly thin on which fields are mandatory per mode.

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 75%, so the baseline is 3, but the description adds real semantics: listing_id is mutually exclusive with all other fields, and transaction_type defaults to rent while sale estimates cover fewer cities and additionally return registered sold deals. It leaves floor, condition, property_type and city to the schema, which mostly documents them.

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 and resource ('grounded rent or sale price estimate from Dorit's listing corpus') and enumerates exactly what comes back: headline figure, low–high band, sample size and window. It also distinguishes two operating modes (location+rooms subject vs. a single listing_id), which no sibling (search_listings, get_listing, coverage, neighborhood_context) offers.

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?

Names the two calling modes and the parameters that select them ('location + rooms' vs. 'listing_id'), and spells out the refusal codes with the explicit instruction never to substitute a guess. It stops short of naming a sibling tool to use instead (e.g. search_listings for browsing comps), so routing across the sibling set is left implicit.

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

All Dorit 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?