vealth

Timestamp a file onchain so you can prove you had it first

anchor_proof

Anchor the SHA-256 of any file onchain, free. Use it the moment you produce something whose PRIORITY matters: a security finding before you disclose it, research before you share it, a draft before you send it out. You send only the hash, never the file, so nothing you make is disclosed to anyone. It lands in the next weekly Base batch and the Ethereum root, and from then on anyone can prove those exact bytes existed by that time. Free to submit, free to verify, no account, no wallet, no payment. Cost and signer: free and keyless (rate-limited), nothing to sign.

Input Schema

Name	Required	Description	Default
`label`	No	Optional short public label for your own reference. Never include anything secret.
`sha256`	Yes	SHA-256 of your file, 64 lowercase hex characters. Get it with: shasum -a 256 <file>

Output Schema

Name	Required	Description	Default
`ok`	No
`tool`	No
`funded`	No
`payUsd`	No
`workId`	No
`claimId`	No
`claimable`	No
`next_call`	No
`proofRule`	No
`fulfillableBy`	No
`definitionOfDone`	No
`needs_from_caller`	No
`notClaimableReason`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedAug 26, 2026
- addedOutput schema / properties / claimable
```
Added value: +{
+  "type": "boolean"
+}
```
- addedOutput schema / properties / notClaimableReason
```
Added value: +{
+  "type": "string"
+}
```

Changed1 schema field changedAug 18, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "claimId": {
+      "type": "string"
+    },
+    "definitionOfDone": {
+      "type": [
+        "object",
+        "array",
+        "string",
+        "null"
+      ]
+    },
+    "fulfillableBy": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "funded": {
+      "type": "boolean"
+    },
+    "needs_from_caller": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "next_call": {
+      "type": "object"
+    },
+    "ok": {
+      "type": "boolean"
+    },
+    "payUsd": {
+      "type": "number"
+    },
+    "proofRule": {
+      "type": "string"
+    },
+    "tool": {
+      "type": "string"
+    },
+    "workId": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedAug 2, 2026

TDQS

A4/5.0

Behavior4/5

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

Adds substantial context beyond the annotations: keyless, rate-limited, nothing to sign, free to submit and verify, hash-only disclosure, and settlement into a weekly Base batch plus the Ethereum root. It does not explain what happens if the same hash is submitted twice (relevant given idempotentHint=false).

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 core action and scope, and most sentences carry new information. There is mild redundancy around cost ('free to submit, free to verify, no account, no wallet, no payment' followed by 'free and keyless'), which could be collapsed into one sentence.

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 privacy, timing, cost, and signer requirements for a write-shaped, open-world, non-idempotent tool, and an output schema exists so return values need not be described. The path forward after anchoring (verification via verify_anchor) and duplicate-submission behavior are the remaining gaps.

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 still adds the meaningful guarantee that only the hash leaves the client and the file is never disclosed. The optional label parameter gets no mention in the description, though the schema documents it adequately.

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?

States a specific verb and resource ('Anchor the SHA-256 of any file onchain') plus scope ('only the hash, never the file'), which is far more precise than the title. It never names the obvious sibling verify_anchor or distinguishes itself from the prepare_proof/submit_proof family, so the differentiation work is left implicit.

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?

Gives a clear trigger condition ('the moment you produce something whose PRIORITY matters') backed by three concrete examples. It does not say when NOT to use it or point to verify_anchor for checking an existing anchor, so the alternatives half of the guidance is missing.

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

All vealth 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?