MINT Protocol — Universal Work Attestation

Mint Attest

mint_attest

Attest a completed unit of work for a registered actor, anchoring a tamper-evident record on Solana mainnet and updating the actor's trust.

PRICING: FREE. Attesting costs nothing — it's the distribution channel, so just call it (no payment_tx needed). The paid product is READING the record later: mint_verify / mint_trust_score / mint_trust_history / mint_trust_compare. (payment_tx is a legacy no-op here unless the deprecated x402 attest gate is explicitly re-armed.)

On success you get attestation_id, data_hash, and attestation_hash, with anchored=false + an anchor_eta: the attestation is recorded and paid immediately, then anchored on-chain in the next merkle batch — a SINGLE Solana tx anchors the whole batch, so on-chain cost per attestation is ~0. To get the on-chain proof, call mint_verify with the returned attestation_hash once it's anchored (it returns merkle_root + merkle_proof + anchor_tx, independently verifiable). Surface the attestation_hash so the work can be verified later.

Input Schema

Name	Required	Description
`mint_id`	Yes	the actor's MINT id from mint_register ("MINT-xxxxxx").
`summary`	Yes	short human description of what was done and the result.
`metadata`	No	optional free-form JSON folded into the hashed payload.
`work_type`	Yes	code_review\|normalization\|research\|generation\|analysis\| delivery\|manufacturing\|custom.
`input_hash`	No	optional sha256 of the work's input.
`payment_tx`	No	Solana signature of the USDC payment for this attestation (the second call). Omit it on the first call to receive the 402 payment instructions.
`output_hash`	No	optional sha256 of the work's output.
`duration_seconds`	Yes	wall-clock seconds the work took (> 0).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedJun 10, 2026

addedInput schema / properties / payment_tx

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Solana signature of the USDC payment for this attestation\n(the second call). Omit it on the first call to receive the 402\npayment instructions."
+}

First observedJun 9, 2026

TDQS

A4.3/5.0

Behavior5/5

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

No annotations exist, so the description carries the full burden and does so: cost model (free, ~0 on-chain cost via merkle batching), the async lifecycle (anchored=false plus anchor_eta on the first response), the exact success fields returned, and the follow-up needed to obtain merkle_root/merkle_proof/anchor_tx. It also explicitly resolves the payment_tx ambiguity by declaring it a legacy no-op unless the x402 gate is re-armed.

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?

Well front-loaded: purpose first, then a PRICING block, then the return/lifecycle story. Slightly padded by restatement ("PRICING: FREE. Attesting costs nothing — it's the distribution channel") and the marketing framing, which could be one sentence instead of three.

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?

Despite an output schema being present, the description adds what the schema cannot convey: the asynchronous anchoring window and the verify step required to make the proof useful. An agent has everything needed to call it correctly and to tell the user what to do next.

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 is 3; the description earns above that by correcting the schema's implied meaning for payment_tx (schema says USDC payment signature, description says legacy no-op) and by explaining what to do with the returned attestation_hash. It adds no detail on the work_type taxonomy or hashing fields beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

A specific verb and resource: "Attest a completed unit of work for a registered actor," plus the concrete effect (Solana anchor + trust update). It explicitly separates this tool from the read-side siblings (mint_verify, mint_trust_score, mint_trust_history, mint_trust_compare), though it never mentions mint_batch_attest, the one sibling that most plausibly competes for the same call.

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?

Strong conditional guidance: call this freely because it is free, then call mint_verify with the returned attestation_hash once anchoring completes. It also pre-empts the wrong usage ("no payment_tx needed") and explains the legacy field. It stops short of stating when to prefer mint_batch_attest over this single-attest path.

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

All MINT Protocol — Universal Work Attestation 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.