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

cenogram-mcp-server

Official
by cenogram
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_transaction_farmland

Read-only

Get parcel-level farmland eligibility for a transaction: matched eligible area in m², share of parcel, and feature counts from weekly national data for due-diligence checks.

Instructions

Parcel-by-parcel agricultural land-eligibility breakdown for one transaction, from official nationwide eligibility data (updated weekly): per linked parcel with a matched eligible area - the area in m², its share of the parcel (when the measured area is known) and the number of source features; also how many linked parcels carry a match and the snapshot date. Useful for due diligence on land actually eligible/maintained as agricultural, beyond the paper classification. A parcel with no match returns nothing - absence is NEVER a statement that the property is non-agricultural (small plots not actively farmed are absent, the layer has its own update cadence, older transactions can reference renumbered parcels). Cost: 4 tokens (refunded when there is no eligible area).

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

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

Beyond the readOnlyHint it discloses the crucial interpretive caveat: a no-match result is never proof of non-agricultural status, with three concrete reasons (small unfarmed plots absent, layer update cadence, renumbered parcels on older transactions). It also gives the data refresh cadence and an explicit cost/refund rule, which annotations do not carry.

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?

Purpose and return shape come first, then the caveat and cost. Every sentence carries unique information – no restatement of the name, no filler – despite the density required by the negative-result semantics.

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 carries return semantics itself: per-parcel area in m², share of parcel when measured area is known, source feature count, count of matched parcels, and snapshot date. Combined with the absence caveat and cost note, an agent has everything needed to call and interpret it.

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?

Schema coverage is 50% – only transaction_id is documented as the UUID from a search result – and the description adds nothing about the parameters. In particular it does not clarify that transactionId and transaction_id are duplicate aliases of the same UUID, an ambiguity an agent could stumble on.

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 opening states a specific verb+resource+scope: a parcel-by-parcel agricultural land-eligibility breakdown for a single transaction, drawn from nationwide official data. It is clearly separable from neighboring tools such as get_parcel_land_class (paper classification) and the other get_transaction_* environment lookups.

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?

It gives a clear usage context ('useful for due diligence on land actually eligible/maintained as agricultural, beyond the paper classification') and a cost note, which implies the alternative source. It never names a sibling tool explicitly or states when not to call it, so it stops short of a full routing rule.

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