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

cenogram-mcp-server

Official
by cenogram
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_transaction_flood

Read-only

Break down flood hazard per linked plot in a transaction: worst category, hazard type, share inside mapped flood zones, and per-scenario return periods. Use after a search flags flood_risk.

Instructions

Parcel-by-parcel flood-hazard breakdown for one transaction: per linked plot in a mapped flood zone - the worst hazard category (high/medium/low, ~1-in-10-year to ~1-in-500-year), hazard type (river/coastal/infrastructure), the share of the plot inside the zone and the per-scenario list with return periods. Use it after a search whose result shows flood_risk (search_transactions and search_by_area surface it inline; search_by_polygon does not). For a parcel with no transaction, get_parcel_report lists the same scenarios. Land in no mapped zone returns nothing - absence of a zone is never asserted as "safe". Cost: 4 tokens (refunded when there is no flood 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.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description still adds genuinely useful context the annotations cannot: empty results when no mapped zone exists, an explicit warning that absence is not an assertion of safety, and a stated cost of 4 tokens refunded when no flood data. It doesn't describe ordering or the exact shape of the per-plot payload, but the behavioral cues it does give are strong.

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?

The high-value usage rule and cost/empty-result caveats are front-loaded and every sentence carries information. The opening sentence is dense with clause-heavy enumeration, but that density is payload description rather than padding.

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?

With no output schema, the description carries the full burden of describing return values and does so field by field. Combined with the empty-result semantics, the cost note, and the sibling fallbacks, an agent has everything needed to call this correctly and interpret a null response.

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?

At 50% schema coverage and zero parametrization in the description ('for one transaction'), the baseline of 3 applies. Neither the schema nor the description resolves the real ambiguity: transactionId and transaction_id are duplicate optional aliases with required=[] and no stated either/or rule in the schema for transactionId.

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?

Names a specific verb and resource ('flood-hazard breakdown for one transaction') and enumerates exactly what comes back: hazard category, hazard type, share of plot in zone, and per-scenario return periods. That precision also distinguishes it from the sibling get_flood_risk, which is not transaction-scoped.

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?

Gives an explicit trigger ('after a search whose result shows flood_risk') and names which searches surface it inline (search_transactions, search_by_area) versus which do not (search_by_polygon). It also routes the no-transaction case to get_parcel_report, so the agent has a complete decision tree.

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