Skip to main content
Glama

Cenogram - Polish Real Estate Data

get_transaction_nature

Read-only

Get the parcel-by-parcel nature breakdown for one transaction: for each linked plot with a nature signal — the nearest forest within 2 km (forest_distance_m in metres, 0 = the plot overlaps forest, with its overlap share) and any overlapping protected natural areas: the sharpest form (protection_rank 1 = national park, 2 = nature reserve, 3 = Natura 2000, 4 = landscape park, 5 = protected landscape, 6 = other), building_restriction ('statutory_ban' = a build ban that follows directly from the Nature Protection Act for national parks and reserves, 'conditional' = restrictions depend on the act that established the area), the share of the plot under protection, and the named areas. This describes the SOURCE of a restriction (statute vs the establishing act), never the outcome of a specific permitting case, and is not legal advice. Forest is an amenity signal (proximity), protected areas a due-diligence one (build limits). Search results do not carry a nature signal, so call this tool directly on a transaction id whenever forest proximity or protected-area build limits matter. Use it after a search on land plots. An empty result is NEVER a statement that building is allowed — this layer does not cover local zoning plans, planning-permission decisions or areas under designation. A buffer zone around a park or reserve IS reported, as form 'buffer_zone' at rank 6, and never as a statutory ban. An empty result also says which kind of empty it is: either the plots were checked and carry no signal, or no nature reference data is held for them yet and nothing was checked — the second is never a finding that there is no forest or protected area. Cost: 4 tokens (refunded on any empty result).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
transaction_idYesTransaction id (UUID) from a search_transactions / search_by_area / search_by_polygon result.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

The description gives extensive behavioral disclosure beyond annotations: it clarifies that an empty result is never a guarantee of no restrictions, distinguishes between 'no parcels checked' vs 'no reference data,' and explains that the output describes the source of restrictions, not permitting outcomes. It also states the cost (4 tokens) and refund behavior. No contradiction with readOnlyHint=true.

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 description is front-loaded with the core purposeтные and then provides rich semantics. However, it is quite long and includes details like exact protection ranks and the cost that could be presented more concisely or moved to an output schema. Still, each sentence adds meaningful decision-relevant 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?

With only one parameter and no output schema, the description is remarkably complete: it explains input provenance, output meaning, rank semantics, empty-result interpretation, and the source-vs-outcome limitation. It lacks only a brief note about the exact response format, but the semantic coverage is strong.

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?

There is only one parameter and schema coverage is 100%; the schema already names it as a UUID from search results. The description adds the context that the id comes from search_transactions or similar tools, but this is minimal additional semantic value beyond 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?

The description opens with a specific verb and resource: 'Get the parcel-by-parcel nature breakdown for a single transaction.' It clearly enumerates what the tool returns (forest distance, protection rank, overlap share, named areas) and distinguishes itself from search tools by noting that 'search results do not carry a nature signal.'

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?

The description gives explicit when-to-use guidance: 'call this tool directly on a transaction id' when forest proximity or protected-area due diligence matters, and it excludes what the tool is not (not legal advice, not about permitting outcomes). It does not name a specific sibling alternative, but it clearly differentiates from the search workflow.

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