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

cenogram-mcp-server

Official
by cenogram
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_transaction_permits

Read-only

Retrieves building-permit and works-notification history for a transaction's parcels, helping you screen what was built or approved on the land since 2016.

Instructions

Building-permit history for one transaction's parcels, from the national registry of building permits and works notifications (records since 2016): per case - kind (permit / notification), works type, object category, authority, date, address, volume. Use it after a search to screen what was built or approved on the land. Match is by the parcel's current identifier, so splits/merges break the link. Permits are held once a decision is issued (its outcome, granted or refused, is not held); notifications only where accepted without objection; pending cases not at all. For a parcel with no transaction, get_parcel_report lists the cases in its building-activity section. For what is being built around a point, use get_permits_in_area. Three coverage states: covered (at least one registered case), covered_no_data (the transaction exists, its parcels have no case), not_covered (no transaction with this id). An empty result never confirms that nothing was planned. Cost: 4 tokens (refunded when there is no record or no such transaction).

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

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

Annotations already establish a safe read operation, but the description adds substantial behavioral context: linkage is by current parcel identifier so splits/merges break it, permit outcome and pending cases are not held, notifications are included only if accepted without objection, and empty results never confirm absence. It also discloses cost and refund conditions.

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 purpose is front-loaded, and the remaining sentences add essential caveats, coverage-state meanings, alternatives, and cost information without filler. The length is justified by the domain complexity and absence of an output schema.

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?

Given no output schema, the description supplies the key return-shape information by listing per-case fields. It also explains coverage states, match limitations, inclusion rules, empty-result interpretation, and cost, making it complete enough for correct invocation.

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 schema covers the UUID pattern and partially describes transaction_id as the transaction id from a search result. The description reinforces that the tool operates on one transaction id, but it does not clarify the transactionId vs transaction_id alias or add further parameter-level guidance 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?

States a specific resource and scope: building-permit history for one transaction's parcels from the national registry, with per-case fields and coverage since 2016. It also distinguishes itself from siblings by naming get_parcel_report and get_permits_in_area for adjacent use cases.

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 to use it after a search to screen what was built or approved on the land. It also routes the agent to alternatives: get_parcel_report when there is no transaction, and get_permits_in_area for nearby point-based permit activity.

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