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

cenogram-mcp-server

Official
by cenogram
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

estimate_land_value

Read-only

Estimate undeveloped land market value from comparable registered transaction prices using coordinates or a parcel ID. Returns per m²/hectare ranges and confidence.

Instructions

[Beta] Estimate an undeveloped plot's market value from comparable registered transaction prices near a point. An orientation estimate, NOT a certified appraisal (operat szacunkowy). Address by lat + lng OR parcelId (the parcel centroid is used) - exactly one. area (m², 100–1000000) is REQUIRED with lat/lng; with parcelId it defaults to the cadastre area. landType: plot (building plot, default) or agricultural (farmland) - the caller chooses. Optional mpzpDesignation narrows the comparables; includeComps (default true) echoes them. Returns the estimate per m² and per hectare, a likely and a wide range, a confidence band, the comparable count and an as_of date (as_of lags by county: estimates are NOT comparable across areas with different as_of). Comparables are chosen by the designation recorded in the transaction register (not a local zoning plan), so this does not assert the plot is buildable. Undeveloped land only. Too few comparables, or an area that cannot be determined → no estimate. Costs 5 API tokens, refunded when no estimate is produced. It can be switched off for maintenance (a plain "temporarily unavailable" reply). Aggregates exclude fractional shares and non-market deeds.

Input Schema

NameRequiredDescriptionDefault
latNoLatitude of the plot (WGS84, Poland); pair with lng. Use this OR parcelId (area is then required).
lngNoLongitude of the plot (WGS84, Poland); pair with lat. Use this OR parcelId (area is then required).
areaNoPlot area in m² (100–1000000). REQUIRED with lat/lng; with parcelId read from the cadastre when omitted.
landTypeNoComparable segment: plot (building plot, default) or agricultural (farmland); the caller chooses.
parcelIdNoFull cadastral id or internal UUID; the parcel centroid is used. Instead of lat/lng.
includeCompsNoEcho the comparables weighed (default true); false = estimate only.
mpzpDesignationNoNarrow comparables to a recorded land-designation token (e.g. 'budownictwoMieszkanioweJednorodzinne'); 'unknown' = none recorded.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

A4.5/5.0
Behavior5/5

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

Despite readOnlyHint=true covering the safety profile, the description adds substantial non-obvious behavior: 5-token cost with refund when no estimate is produced, ability to be disabled for maintenance, county-varying as_of that makes estimates non-comparable, and exclusions of fractional shares and non-market deeds.

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 the core purpose and a clean beta/appraisal disclaimer, then organized into addressing, returns, and caveats. Dense but nearly every sentence carries a constraint an agent needs; a couple of clauses duplicate the schema descriptions verbatim.

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, yet the description enumerates the return payload (per m² and per hectare, likely and wide range, confidence band, comparable count, as_of date) and explains the no-estimate outcome. An agent knows what it will get and when it won't.

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 baseline is 3, but the description adds cross-parameter semantics the schema can't express: the exactly-one rule between lat/lng and parcelId, area's conditional requirement/defaulting, and 'unknown' = no designation recorded. Some sentences do restate schema text, preventing a 5.

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?

Specific verb + resource + scope: 'Estimate an undeveloped plot's market value from comparable registered transaction prices near a point,' plus the explicit 'Undeveloped land only' boundary and the disclaimer that this is not a certified appraisal. It doesn't name the closest ambiguous sibling (estimate_value) to route between them, so it stops short of 5.

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?

States addressing rules precisely: 'lat + lng OR parcelId ... exactly one', area REQUIRED with lat/lng and defaulted from the cadastre with parcelId, and that landType is a caller choice. It also names the failure conditions (too few comparables, undeterminable area) and the maintenance mode.

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