Skip to main content
Glama

FindEstate Real Estate

Compare FindEstate properties

compare_properties
Read-onlyIdempotent

Use this when the user asks to compare 2–5 FindEstate homes, including follow-ups such as compare the first two, show these side by side, which has the lower asking price per m², or palygink pirmus du butus. Call before answering the comparison; earlier search/card facts are not a substitute for this fresh authorization and fact check. Resolve relative choices from the latest relevant displayed order and use the exact returned references in that order; no new search is needed when those references are known. If targets are unclear, clarify first. Opens the comparison inside ChatGPT itself; do not follow with render_findestate_properties. Not for one-home details, project summaries, general advice or investment recommendations. Compares original asking prices, area, asking price per m², sourced total rooms versus bedrooms, floor/year and confirmed parent project. Missing facts stay unknown; unavailable entries give no private reason and must not reuse cached facts. No currency or rental-period normalization, inferred bedrooms, valuations, promised availability, bookings or payments. Current units retain explicit guest viewing/question forms.

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": {
      "items": "<items>"
    },
    "name": "compare_properties"
  }
}

Input Schema

NameRequiredDescriptionDefault
itemsYesTwo to five unique exact individual-property references from prior FindEstate results. Resolve first/second or these homes using the latest relevant displayed order, and preserve the requested order. Pass kind=property, catalogId and id only; never invent IDs, use project summaries or include cached listing facts.
localeNoen

Output Schema

NameRequiredDescriptionDefault
itemsYes
localeYes
statusYes
versionYes
coverageYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover the read-only/idempotent/no-destructive profile, and the description adds substantive behavior on top: the comparison renders inside ChatGPT rather than following with render_findestate_properties, missing facts remain unknown with no cached reuse or private reasons, and there is no currency or rental-period normalization, no inferred bedrooms, valuations, bookings or payments. It also notes that current units retain guest viewing/question forms, which is non-obvious side behavior.

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 trigger examples and the do-not-follow-with rule are front-loaded well, but the body is a dense run-on of caveats and includes a garbled multilingual example ('palygink pirmus du butus') that adds noise without meaning. Several exclusion clauses could be consolidated without losing information.

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?

An output schema exists, so the description correctly does not spend words on return values and instead covers scope, ordering, uncertainty handling and prohibited normalizations. The one gap is the unexplained locale parameter and the dangling mention of guest viewing/question forms, whose triggering behavior is not fully spelled out.

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?

The items parameter is already thoroughly documented in the schema, including the 2-5 limit, exact reference requirement and order preservation, so the description largely restates it rather than adding syntax. The locale parameter (enum lt/en, default en) is not explained anywhere, leaving half the schema-description coverage unaddressed. The added value is the clarification-vs-resolve rule for ambiguous targets, which is marginal but real.

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, resource and cardinality: compare 2-5 FindEstate homes, and enumerates the comparison axes (asking price, area, price per m², rooms vs bedrooms, floor/year, parent project). It explicitly bounds itself against siblings by ruling out one-home details and by instructing not to follow with render_findestate_properties.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives when-to-use triggers in user language (compare the first two, side by side, lower price per m²) and an explicit when-not list (one-home details, project summaries, general advice, investment recommendations). It also resolves the sequencing question versus search tools: 'no new search is needed when those references are known' and 'clarify first' when targets are unclear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources