Skip to main content
Glama
Sign In

Verifyum

by com.verifyum
OverviewDiscussionsAdmin

Anchor a prepared Verifyum commitment

verifyum_anchor_commitment
DestructiveIdempotent

Submit one locally calculated Verifyum version 2 commitment. Accepts only the commitment and an idempotency key. Never send a file, filename, raw file hash, nonce or private manifest. The caller must hash the file and build the private manifest on its own machine first, as documented at https://verifyum.com/agents. This creates a real public transaction on Solana Mainnet. Public use is currently free and the network fee is currently paid by AI SENSE AS. That is a current service policy, not a permanent pricing guarantee. Create proofs only on clear user intent, never speculatively, in bulk, or as a hidden side effect. When retrying, reuse the exact same commitment and idempotency key.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "commitment": "<commitment>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "verifyum_anchor_commitment"
  }
}

Input Schema

NameRequiredDescriptionDefault
commitmentYessha256: followed by 64 lowercase hexadecimal characters
idempotency_keyYes16 to 128 URL-safe characters, reused verbatim on retries

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark destructive=true, idempotent=true and openWorld=true, but the description goes well beyond them by disclosing that this writes a real, permanent Solana Mainnet transaction, that the service is currently free with fees paid by AI SENSE AS as revocable policy rather than guarantee, and how idempotent retries behave. It also draws explicit privacy boundaries about what must never be transmitted.

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, then constraints, then policy caveats; every sentence carries operational weight. It is on the dense side (six sentences of prose) but no sentence is filler or restatement.

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?

Covers the high-stakes aspects an agent needs: irreversibility, cost/policy, privacy, and retry semantics. The remaining gap is that with no output schema, the description never says what comes back (proof identifier, transaction signature, or status) or how to use it, which matters for a permanent write.

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%, so the baseline would be 3, but the description adds genuine meaning: exactly two inputs are accepted, the caller computes the commitment locally, and the idempotency key must be reused verbatim on retries. It also constrains what must NOT be sent (file, filename, raw hash, nonce, private manifest), which the schema cannot express.

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: 'Submit one locally calculated Verifyum version 2 commitment,' and adds the concrete effect ('creates a real public transaction on Solana Mainnet'). The anchoring/commit action is unmistakably distinct from the sibling read tools verifyum_get_proof and verifyum_verify_public_proof.

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 explicit when-not guidance: 'Create proofs only on clear user intent, never speculatively, in bulk, or as a hidden side effect,' plus a retry rule ('reuse the exact same commitment and idempotency key'). The precondition that the caller must hash and build the manifest first is stated as a hard sequencing requirement.

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

All Verifyum toolsInspect
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