Skip to main content
Glama
Sign In
cenogram-mcp-server

cenogram-mcp-server

Official
by cenogram
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

estimate_value

Read-only

Calculate an apartment's market value from nearby registered transaction prices; supply area and coordinates or parcel ID to receive ranges, confidence, and comparables.

Instructions

[Beta] Estimate an apartment's market value from comparable registered transaction prices near a point. An orientation estimate, NOT a certified appraisal (operat szacunkowy): it ignores condition, finish standard and floor. Address by lat + lng OR parcelId (the parcel centroid is used) - exactly one. area (usable m², 10–250) is REQUIRED. Optional: rooms (1–10) and market (primary/secondary) narrow the comparables; includeComps (default true) echoes them. Returns the point estimate, a likely and a wide range, a confidence band, the comparable count and an as_of date; as_of lags by county, so estimates are NOT comparable across cities with different as_of. Apartments only; for a building plot or farmland use estimate_land_value. Too few comparables → no estimate. Costs 5 API tokens, refunded when no estimate is produced. Aggregates exclude fractional shares and non-market deeds.

Input Schema

NameRequiredDescriptionDefault
latNoLatitude of the apartment (WGS84, Poland); pair with lng. Use this OR parcelId.
lngNoLongitude of the apartment (WGS84, Poland); pair with lat. Use this OR parcelId.
areaYesApartment usable area in m² (REQUIRED, 10–250).
roomsNoRoom count (1–10); narrows comparables to ±1 room.
marketNoRestrict comparables to the primary (new-build) or secondary market.
parcelIdNoFull cadastral id (slash or dash form) or internal UUID; the parcel centroid is used. Instead of lat/lng.
includeCompsNoEcho the comparables weighed (default true); false = estimate only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.18.0
    • changedInput schema / properties / area / description
      Previous value: -"Apartment usable area in m² (REQUIRED, 10–250). Estimates for 300+ m² are unreliable and rejected."New value: +"Apartment usable area in m² (REQUIRED, 10–250)."
    • changedInput schema / properties / includeComps / description
      Previous value: -"Echo the nearest comparables the estimate weighed (default true). Set false for the estimate only."New value: +"Echo the comparables weighed (default true); false = estimate only."
    • changedInput schema / properties / lat / description
      Previous value: -"Latitude of the apartment (WGS84, Poland). Must be paired with lng. Use this OR parcelId."New value: +"Latitude of the apartment (WGS84, Poland); pair with lng. Use this OR parcelId."
    • changedInput schema / properties / lng / description
      Previous value: -"Longitude of the apartment (WGS84, Poland). Must be paired with lat. Use this OR parcelId."New value: +"Longitude of the apartment (WGS84, Poland); pair with lat. Use this OR parcelId."
    • changedInput schema / properties / market / description
      Previous value: -"Restrict comparables to the primary (new-build) or secondary market (optional)."New value: +"Restrict comparables to the primary (new-build) or secondary market."
    • changedInput schema / properties / parcelId / description
      Previous value: -"Full cadastral id (slash or dash form) or internal UUID; the parcel centroid is used. Use instead of lat/lng."New value: +"Full cadastral id (slash or dash form) or internal UUID; the parcel centroid is used. Instead of lat/lng."
    • changedInput schema / properties / rooms / description
      Previous value: -"Room count (1–10, optional) — narrows the comparables to ±1 room."New value: +"Room count (1–10); narrows comparables to ±1 room."
  2. First observedv0.5.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial context beyond that: beta status, that this is not a certified appraisal and ignores condition/finish/floor, the as_of county lag making cross-city comparison invalid, the 5-token cost with refund policy, and the exclusion of fractional shares and non-market deeds. It could go slightly further on latency or payload size, but the behavioral disclosure is unusually thorough.

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-loads the core purpose, then address rules, then return shape and caveats. Dense but every sentence carries information (ranges, as_of caveat, cost/refund, exclusions). Slightly long, but no filler sentences.

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?

No output schema exists, and the description fully covers the return shape: point estimate, likely and wide range, confidence band, comparable count, and as_of. With usage rules, caveats, and cost behavior all stated, an agent has everything needed to call it correctly.

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 100%, so parameters are already documented; the description reinforces the critical invariants (exactly one of lat/lng vs parcelId, area required at 10–250 m²) and explains what rooms/market and includeComps actually do to the result. This adds decision-relevant meaning rather than merely repeating 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?

States a specific verb and resource ('Estimate an apartment's market value') and immediately clarifies the scope: comparable registered transactions near a point, apartments only. It explicitly distinguishes itself from the sibling estimate_land_value for plots/farmland, so the agent can choose without inspecting schemas.

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 explicit routing: apartments only, use estimate_land_value for building plots or farmland, and too few comparables yields no estimate. It also specifies the address rule (lat+lng OR parcelId, exactly one) and that area is required, covering both when to use and how to invoke.

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

Deploy Server

Other Tools