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

cenogram-mcp-server

Official
by cenogram
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_transaction_planning

Read-only

Fetches general-plan zoning for a transaction's plots, returning zone symbols, coverage shares, building parameters, and overlay areas to answer feasibility and permitted-use questions.

Instructions

General-plan (plan ogólny, POG) zoning for one transaction's land: per linked plot, the zones covering it - symbol, name, share of the plot, the building parameters the plan sets (max height, max development intensity, max built-up coverage, min biologically active area) - plus overlay areas (infill development area / obszar uzupełnienia zabudowy, central development area). Use it for feasibility and permitted-use questions on a plot. Coverage is THREE-STATE: 'covered' returns zone data; 'covered_no_data' = the municipality has an adopted general plan but no zone data covers these plots yet; 'not_covered' = no published general-plan data for the municipality yet - NEVER a claim that it has no plan (general plans are still being adopted). Cost: 4 tokens (refunded for covered_no_data and not_covered).

Input Schema

NameRequiredDescriptionDefault
transactionIdNo
transaction_idNoTransaction id (UUID) from a search result. This or transactionId is required.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.18.0
    • addedInput schema / properties / transactionId
      Added value: +{
+  "pattern": "^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$",
+  "type": "string"
+}
    • changedInput schema / properties / transaction_id / description
      Previous value: -"Transaction id (UUID) from a search_transactions / search_by_area / search_by_polygon result."New value: +"Transaction id (UUID) from a search result. This or transactionId is required."
    • removedInput schema / required
      Removed value: -[
-  "transaction_id"
-]
  2. First observedv0.5.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, yet the description adds substantial context beyond them: the three-state coverage model ('covered'/'covered_no_data'/'not_covered'), the explicit warning that 'not_covered' is never a claim that no plan exists, and the cost of 4 tokens with refund conditions for the two non-data states. That is exactly the kind of operational and interpretive context an agent cannot get from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The returned fields and the usage rule come first, followed by the coverage semantics and cost. The parenthetical Polish terms are domain-necessary, and no sentence is filler.

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?

There is no output schema, so the description must describe return values – it does, enumerating zone attributes and overlay areas. Combined with the coverage-state explanation, an agent knows what it will get and how to read an empty result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50% – transaction_id is documented but transactionId is bare – and the description never mentions either parameter, how to obtain a transaction id, or why two aliases for the same UUID exist. With half the parameters undocumented and no compensating text, the agent is left to infer the input contract.

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: general-plan (POG) zoning for one transaction's land, enumerating the returned fields (zone symbol, name, share, max height, development intensity, built-up coverage, biologically active area) and overlay areas. This clearly separates it from the many sibling get_transaction_* hazard tools, which cover flood, heritage, nature, transit, etc.

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?

"Use it for feasibility and permitted-use questions on a plot" gives explicit when-to-use guidance, and the coverage discussion implies when results will be empty. It never names an alternative tool or states exclusions, so it stops short of the top tier.

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