Skip to main content
Glama

Rokha

by ai.rokha
OverviewDiscussionsAdmin

What a payment receipt looks like, and whether an image is it

singularityagent__receipt_art
Read-only

Every Singularity payment QR is artwork derived from the payment's reference — the pubkey attached to the transfer that makes it findable on chain. Because it is derived rather than stored, the picture is a fingerprint of one payment: two payments can never render alike, and anyone holding the reference can re-derive it. Pass a reference (or a receipt uri of the form /.json, which is how the reference reaches the chain) to get the style traits a marketplace would list. Pass link as well to render the code. Pass image to ask the question that matters: is this picture the one this reference generates? A receipt NFT's metadata is served by a host that can change it, and this is how a holder checks the image they are being shown is evidence of their payment rather than something swapped in. matches: false is not proof of fraud — it means the image is not evidence. This is pure: it reads no chain, fetches nothing, and signs nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uriNoA receipt metadata uri to read the reference out of, when you do not have it directly.
linkNoThe solana: payment link, needed to render or compare a picture.
imageNoAn SVG to check against what the reference generates. Requires `link`.
referenceNoThe payment reference the art is derived from.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / additionalProperties
      Previous value: -trueNew value: +false
    • addedInput schema / properties
      Added value: +{
+  "image": {
+    "description": "An SVG to check against what the reference generates. Requires `link`.",
+    "type": "string"
+  },
+  "link": {
+    "description": "The solana: payment link, needed to render or compare a picture.",
+    "type": "string"
+  },
+  "reference": {
+    "description": "The payment reference the art is derived from.",
+    "type": "string"
+  },
+  "uri": {
+    "description": "A receipt metadata uri to read the reference out of, when you do not have it directly.",
+    "type": "string"
+  }
+}
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already mark the tool as read-only and open-world, and the description goes further by stating it reads no chain, fetches nothing, and signs nothing. It also discloses the host-can-change-metadata risk and clarifies that matches:false is not proof of fraud.

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 description is dense but not bloated; every sentence adds a caveat or usage detail. It is not maximally front-loaded, but the conceptual framing is necessary for correct interpretation of the verification behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 covers the key return concepts: style traits, rendered code, and the matches boolean. It does not enumerate exact response fields, but it is sufficient for an agent to call the tool correctly given the optional parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds meaningful semantics beyond the schema: the uri format <base>/<reference>.json, the dependency of image on link, and the role of reference as the derivation seed. This exceeds the baseline.

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 description clearly states what the tool does: derive payment receipt art from a reference, render it with a link, and verify whether an image matches the reference. It distinguishes the verification question from proof-of-fraud and differentiates the tool from siblings like prove_payment.

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 explicit parameter-combination guidance: pass reference or uri for style traits, add link to render, add image to compare. It explains the meaning of matches:false and the mutable-metadata caveat, though it does not name sibling alternatives explicitly.

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

All Rokha toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources