GYOTAK Fish Market

Verify KOMON record on chain

verify_komon

Read-onlyIdempotent

Verify a GYOTAK KOMON record directly from the Midnight blockchain. Reads on-chain state and returns the raw hex plus decoded fields for independent verification. Unlike get_komon_records (which returns GYOTAK's database), this reads directly from the chain. Shielded records do not put the GPS coordinates on the chain, only a hash of them (gpsHash); the region is a label set by GYOTAK. GYOTAK checks the region range when recording, but the range used is not stored in the record, so the region cannot be confirmed from the chain. Currently preprod only.

Input Schema

Name	Required	Description
`komonId`	No	Filter to a specific komon record by ID. Omit to return all records.
`network`	No	Midnight network (default: preprod)
`contractAddress`	No	Midnight komon contract address (64-char hex)

Output Schema

Name	Required	Description
`error`	No	Same text as content when the input or the lookup failed
`source`	No	Where the on-chain state was read from
`message`	No	Same text as content when there is nothing to show
`records`	No
`raw_state`	No
`gps_recoverable`	No
`availableKomonIds`	No	Listed when no record matched komonId
`verification_note`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "availableKomonIds": {
+      "description": "Listed when no record matched komonId",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "error": {
+      "description": "Same text as content when the input or the lookup failed",
+      "type": "string"
+    },
+    "gps_recoverable": {
+      "type": "boolean"
+    },
+    "message": {
+      "description": "Same text as content when there is nothing to show",
+      "type": "string"
+    },
+    "raw_state": {
+      "type": "string"
+    },
+    "records": {
+      "items": {
+        "properties": {
+          "committedAt": {
+            "type": "number"
+          },
+          "gpsHash": {
+            "type": "string"
+          },
+          "komonCommit": {
+            "type": "string"
+          },
+          "komonId": {
+            "type": "string"
+          },
+          "lat": {
+            "type": "number"
+          },
+          "lng": {
+            "type": "number"
+          },
+          "photoHash": {
+            "type": "string"
+          },
+          "privacyMode": {
+            "type": "string"
+          },
+          "region": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "komonId"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "source": {
+      "description": "Where the on-chain state was read from",
+      "properties": {
+        "block_height": {
+          "type": "integer"
+        },
+        "contract_address": {
+          "type": "string"
+        },
+        "indexer_url": {
+          "type": "string"
+        },
+        "network": {
+          "type": "string"
+        },
+        "tx_hash": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "indexer_url",
+        "contract_address",
+        "network"
+      ],
+      "type": "object"
+    },
+    "verification_note": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedSep 6, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations by disclosing what the chain actually contains: shielded records store only gpsHash, not coordinates, and the region is a GYOTAK-side label whose range is not persisted, so it cannot be confirmed on-chain. Also flags the preprod-only limitation and what is returned (raw hex plus decoded fields). This is exactly the kind of trust-boundary context an agent needs before reporting a 'verification' result.

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 action and the sibling differentiation before the caveats, and every sentence carries substantive information. Slightly dense in the middle (gpsHash/region explanation runs long), but no sentence is 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?

An output schema exists, yet the description still characterizes the return shape ('raw hex plus decoded fields'), and it covers the critical semantic caveats about shielded records and unverifiable regions. For a read-only verification tool with full schema coverage, nothing an agent needs to interpret results correctly is missing.

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 description coverage is 100%, so all three parameters are already documented, warranting the baseline 3. The description adds only an implicit note that the record is fetched from chain state and that mainnet is not yet available, without elaborating on komonId filtering, contractAddress format, or the mainnet enum value the schema still exposes.

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 ('Verify a GYOTAK KOMON record directly from the Midnight blockchain') and explicitly contrasts scope with the sibling get_komon_records ('which returns GYOTAK's database'). An agent can distinguish the two without opening either schema.

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?

Names the alternative (get_komon_records) and the condition that selects this tool ('for independent verification', reads directly from chain). Adds the environmental constraint 'Currently preprod only', which further scopes usage. Lacks an explicit statement of when NOT to use it beyond the sibling contrast, so not quite a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All GYOTAK Fish Market tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?