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

cenogram-mcp-server

Official
by cenogram
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_transaction_heritage

Read-only

Get a parcel-by-parcel heritage-listing breakdown for a transaction, showing protection status, protected area share and heritage entries for each linked plot.

Instructions

Parcel-by-parcel heritage-listing breakdown for one transaction: per linked plot with a detected listing - the status (listed = a protected monument on/at the plot; zone = within a protected urban layout or the designated surroundings of a monument), the share of the plot inside the protected area (when measurable) and the entries (category, name, function, period, entry date). Use it after a search whose result shows a heritage listing (search_transactions and search_by_area surface heritage_status inline; search_by_polygon does not). For a parcel with no transaction, get_parcel_report lists the same entries. No detected listing returns nothing - absence of a detection is never "not listed". Indicative data: the regional heritage conservator makes the binding determination. Cost: 4 tokens (refunded when there is no heritage data).

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.6/5.0
Behavior5/5

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

Goes well beyond readOnlyHint/non-destructive annotations: it discloses the cost (4 tokens, refunded when there is no heritage data), the authoritative caveat (indicative data; the regional conservator makes the binding determination), and the critical semantic that no detected listing is not the same as 'not listed'. Those are exactly the traits an agent cannot infer 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.

Conciseness4/5

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

Front-loaded with the purpose, then output shape, then usage routing, then caveats and cost — a sensible ordering with no filler. The first sentence is dense and clause-heavy, but every element carries information.

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, and it does: status meanings for 'listed' vs 'zone', the measurable protected-area share, and the entry fields. Combined with usage routing, cost, and authority caveats, an agent has everything needed to call it and interpret the result.

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 two schema parameters are an alias pair (transactionId / transaction_id) at 50% description coverage, and the one documented property already says 'This or transactionId is required.' The description only implies 'one transaction' without naming the parameter or noting the alias, so it adds no real meaning over the schema — adequate but not compensating for the coverage gap.

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: a parcel-by-parcel heritage-listing breakdown for one transaction, enumerated down to fields (status, protected share, entries with category/name/function/period/entry date). It clearly separates itself from get_parcel_report (no-transaction case) and the search tools, so an agent can identify it without opening the schema.

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?

Explicitly says when to use it ('after a search whose result shows a heritage listing') and names the alternatives: search_transactions and search_by_area surface heritage_status inline, search_by_polygon does not, and get_parcel_report covers a parcel with no transaction. This is a complete routing statement with both positive and negative conditions.

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