vealth

Prepare signed proof of finished work (step 1 of 2)

prepare_proof

Read-onlyIdempotent

You did the work — start handing in proof. Pass the packet's workId, your claimId (from submit_claim), your wallet, and proof items matching the packet's own proof line (photos with GPS for field work; documents/text for digital work). On an hours-eligible job, state the hours you actually worked as hoursClaimed, and whatever the job asks to be counted as counts: you state them, and the human who accepts decides the accepted figure. Returns MESSAGE_TO_SIGN and BODY_JSON. Submitting proof is FREE when signed — a worker is never charged at the moment they have earned the right to be asked for nothing. Sign, then call submit_proof within 5 minutes.

Input Schema

TableJSON Schema

Name	Required	Description
`gps`	No	For geolocated field work: {lat, lng} captured ON SITE — the gate refuses geolocated proof without it.
`crew`	No	Optional, for a manager handing in proof for a crew: the people who did the work, 1 to 25 of {"ref":"amina","hoursClaimed":2}, refs as on the claim. Either every person states hoursClaimed or none does; stated hours add up to the proof's hoursClaimed (omit that and their sum becomes it). The human who accepts decides the accepted total, split back across the crew in proportion (equally with no per-person hours). Omit crew on a managed claim and the claim's crew carries over.
`counts`	No	Optional: what the job asked to be counted, in the packet's own units, as plain numbers — {"metres_cleared": 120, "blockages_removed": 4, "check_dams_built": 3}. Lower_snake_case names, at most 40 of them. Recorded with the proof; it decides nothing on its own.
`proofs`	Yes	1-20 proof items. A photo goes in BY REFERENCE: {"type":"photo","upload":"sha256:<hex>","step":1,"capturedAt":"<ISO>"}, where the reference is what `node vealth-agent.mjs proof-photo <workId> <claimId> <photo files>` printed on the person's own machine; the photo bytes never pass through this conversation. A small file may still go inline as {"type":"photo","data":"<base64>"}. Text notes are {"type":"text","data":"…"}. The packet's proof line (get_work_packet) says exactly what it needs.
`workId`	Yes	The packet id.
`claimId`	Yes	Returned by submit_claim.
`hoursClaimed`	No	On an hours-eligible job, the hours you ACTUALLY worked, breaks out — a positive number, at most 168, to 6 decimal places. You state it; the human who accepts decides the accepted figure. Required on such a packet (the completion gate refuses a proof without it), optional everywhere else.
`workerWallet`	Yes	The same 0x… address that claimed.

Output Schema

TableJSON 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.

Changed1 schema field changedSep 23, 2026

addedInput schema / properties / crew

Added value: +{
+  "description": "Optional, for a manager handing in proof for a crew: the people who did the work, 1 to 25 of {\"ref\":\"amina\",\"hoursClaimed\":2}, refs as on the claim. Either every person states hoursClaimed or none does; stated hours add up to the proof's hoursClaimed (omit that and their sum becomes it). The human who accepts decides the accepted total, split back across the crew in proportion (equally with no per-person hours). Omit crew on a managed claim and the claim's crew carries over.",
+  "items": {
+    "properties": {
+      "hoursClaimed": {
+        "type": "number"
+      },
+      "label": {
+        "type": "string"
+      },
+      "ref": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "ref"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changed1 schema field changedSep 23, 2026

changedInput schema / properties / proofs / description

Previous value: -"1-20 proof items, e.g. {\"type\":\"photo\",\"uri\":\"https://…\",\"capturedAt\":\"<ISO>\",\"lat\":…,\"lng\":…}. The packet's proof line (get_work_packet) says exactly what it needs."New value: +"1-20 proof items. A photo goes in BY REFERENCE: {\"type\":\"photo\",\"upload\":\"sha256:<hex>\",\"step\":1,\"capturedAt\":\"<ISO>\"}, where the reference is what `node vealth-agent.mjs proof-photo <workId> <claimId> <photo files>` printed on the person's own machine; the photo bytes never pass through this conversation. A small file may still go inline as {\"type\":\"photo\",\"data\":\"<base64>\"}. Text notes are {\"type\":\"text\",\"data\":\"…\"}. The packet's proof line (get_work_packet) says exactly what it needs."

Changed2 schema fields changedSep 8, 2026

addedInput schema / properties / counts

Added value: +{
+  "description": "Optional: what the job asked to be counted, in the packet's own units, as plain numbers — {\"metres_cleared\": 120, \"blockages_removed\": 4, \"check_dams_built\": 3}. Lower_snake_case names, at most 40 of them. Recorded with the proof; it decides nothing on its own.",
+  "type": "object"
+}

addedInput schema / properties / hoursClaimed

Added value: +{
+  "description": "On an hours-eligible job, the hours you ACTUALLY worked, breaks out — a positive number, at most 168, to 6 decimal places. You state it; the human who accepts decides the accepted figure. Required on such a packet (the completion gate refuses a proof without it), optional everywhere else.",
+  "type": "number"
+}

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.6/5.0

Behavior5/5

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

Beyond the readOnly, idempotent, and non-destructive annotations, the description discloses that the tool returns MESSAGE_TO_SIGN and BODY_JSON rather than submitting anything, that signed submission is free, that there is a 5-minute signing window, and that certain inputs are refused at the gate if missing. This gives the agent a clear behavioral model of a preparation step with no submitted side effects. Nothing contradicts the annotations.

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 front-loaded with the core workflow and then covers optional cases in a structured way. It is long, but the tool is genuinely complex with nested objects and conditional requirements. Some phrasing is dense and repeats the 'human who accepts decides' idea, but each sentence earns its place in the context of a high-complexity tool.

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 an 8-parameter tool with nested objects and an output schema, the description covers prerequisites, optional branches (hours, crew, counts, GPS), the output contract, expiry, cost, and privacy. It tells the agent exactly how to proceed and when to stop before submission. The combination of prose, rich schema, and annotations leaves no major decision uncovered.

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, but the description adds useful meaning by mapping proof types to work types (photos with GPS for field work, documents/text for digital work) and connecting claimId to submit_claim. It reinforces the idea that proof items must match the packet's proof line, which helps assembly beyond raw schema field names. The extra guidance is meaningful but not exhaustive for every edge condition.

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 title and description state a concrete contract: prepare a signed proof by providing workId, claimId, workerWallet, and proof items, and receive MESSAGE_TO_SIGN and BODY_JSON. It is clearly distinguished from submit_proof by being called 'step 1 of 2' and by explicitly instructing the agent to sign and then call submit_proof. The verb, resource, and next step are all specific.

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 clearly defines when to use the tool: after doing the work, as the hand-in step before submit_proof, with claimId from submit_claim and proof items matching the packet's proof line. It gives conditional rules for hoursClaimed, gps, and crew, and states that the completion gate refuses proofs missing required inputs. However, it does not explicitly mention alternative prepare_* tools or say when not to use this one, so it stops short of a 5.

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?