Skip to main content
Glama

verify_on_chain

Creates cryptographic proof of work by anchoring data on Solana. Batch mode proves thousands of events in one transaction; single-payload mode timestamps arbitrary JSON records for tamper-evident verification.

Instructions

Anchor data on Solana mainnet via the MINT relay for cryptographic proof of work. Two modes:

BATCH MODE (batch=true, requires mint_id): Collects every unsettled event for that machine — normalize calls, trigger fires, webhook executions — since the last batch. Computes a Merkle root of their event hashes and anchors that single root on Solana. ONE transaction proves dozens to thousands of events. Returns: merkle_root, event_count, event_types breakdown, tx_signature, verify_url (Solscan link). Cost-efficient — call this once an hour or once a shift per machine, not per event.

SINGLE-PAYLOAD MODE (batch=false, requires payload): Hashes an arbitrary JSON payload deterministically (sorted keys, no whitespace) and anchors the hash. Returns: payload_hash, tx_signature, verify_url. Use for one-off proofs — inspection records, completed work orders, signed reports — where you want a permanent independent timestamp.

USE WHEN: a user wants tamper-proof evidence — settlement of a completed work batch, proof a maintenance window happened, anchoring a quality report, rolling up a day's machine activity into a single verifiable hash. ALWAYS include the verify_url (a Solscan link) in your reply so the user can independently verify on-chain.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mint_idNo
payloadNo
batchNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

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

Given no annotations, the description fully explains the tool's behavior: it anchors data, computes Merkle roots for batches, hashes payloads deterministically, and returns verification links. It does not mention authorization or rate limits, but the core behavior is well covered.

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 description is well-structured with clear headings for each mode and a 'USE WHEN' section. Every sentence is informative and necessary, with no redundancy or fluff. It is concise yet comprehensive.

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?

For a tool with three parameters, no required fields, and an output schema, the description covers all relevant context: purpose, modes, return values (though output schema exists), usage scenarios, and user instructions. It is complete and leaves no ambiguity about when and how to use the tool.

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 description coverage is 0%, so the description must compensate. It explains all three parameters (batch, mint_id, payload) by linking them to the two modes, specifying which are required per mode, and describing the payload hashing. The mint_id parameter could use more detail (e.g., its format or origin), but overall it adds significant semantic value 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?

The description clearly states the tool anchors data on Solana via MINT relay, with two explicit modes (batch and single-payload). It uses a specific verb ('anchor') and resource ('data on Solana mainnet'), and it distinguishes itself from sibling tools which focus on automation and telemetry.

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?

The description includes a 'USE WHEN' section with concrete examples and instructs to always include the verify_url. It differentiates between batch and single modes. However, it does not explicitly state when NOT to use the tool, which slightly reduces the score.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/FoundryNet/forge-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server