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. To count toward a place's Standing, a reading carries measurement.kind "measurement" (with measuredAt, and delta on a re-measure) and a repair carries kind "repair". 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. Cost and signer: free, no gas; the person signs the result with their own wallet or passkey, and the house never holds a key.

Input 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.
`measurement`	No	Optional: what this proof is. A reading: {"kind":"measurement","measuredAt":"<ISO>","delta":0}, with delta on a re-measure (above 0 better, 0 held, below 0 worse). A repair: {"kind":"repair","measuredAt":"<ISO>","delta":1}. Only a reading counts toward a place's Standing. Without it the proof is accepted as usual and covers no condition.
`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

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 changedNov 2, 2026

addedInput schema / properties / measurement

Added value: +{
+  "description": "Optional: what this proof is. A reading: {\"kind\":\"measurement\",\"measuredAt\":\"<ISO>\",\"delta\":0}, with delta on a re-measure (above 0 better, 0 held, below 0 worse). A repair: {\"kind\":\"repair\",\"measuredAt\":\"<ISO>\",\"delta\":1}. Only a reading counts toward a place's Standing. Without it the proof is accepted as usual and covers no condition.",
+  "properties": {
+    "delta": {
+      "type": "number"
+    },
+    "kind": {
+      "enum": [
+        "measurement",
+        "repair"
+      ],
+      "type": "string"
+    },
+    "measuredAt": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

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

Behavior5/5

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

Beyond the readOnlyHint/idempotent annotations, it discloses that the call is free with no gas, that the house never holds a key and the person signs with their own wallet or passkey, that it returns MESSAGE_TO_SIGN and BODY_JSON, and that the signature expires in 5 minutes. It also warns about gate behavior (a proof without hoursClaimed is refused on an hours-eligible job; a geolocated packet refuses proof without GPS). This is substantive context an agent could not infer from annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical facts (free, sign within 5 minutes, returns MESSAGE_TO_SIGN/BODY_JSON) come reasonably early, but the prose is padded with rhetorical asides such as 'a worker is never charged at the moment they have earned the right to be asked for nothing' and 'whatever the job asks to be counted as counts'. Several sentences repeat the same point about the human decider setting the accepted figure.

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?

With an output schema, rich annotations and a fully documented schema, the description fills the remaining gaps well: cost, signer, signature expiry and the hand-off to submit_proof. What is missing is any statement of failure behavior after signature (expiry/retry) and routing to the sibling preparation tools for other proof types.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema already spells out proofs, counts, measurement, crew and hoursClaimed in detail. The description mostly restates those semantics (hours actually worked, measurement.kind determining Standing, proof line from get_work_packet) rather than adding format or edge-case detail the schema lacks. Baseline 3 applies when the schema carries the parameter burden.

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?

The description plus title state a specific verb and resource: prepare a signed proof of finished work as step 1 of a two-step hand-in, requiring workId, claimId, wallet and proof items. It clearly names the successor tool (submit_proof) so an agent knows this is the preparation half. It never mentions the closely-named sibling prepare_physical_proof or prepare_evidence_surface, so differentiation from those is not established.

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?

It gives a concrete workflow context: use this after doing the work, take workId from the packet and claimId from submit_claim, then sign and call submit_proof within 5 minutes. That is a clear when-to-use signal with a hard sequencing constraint. It stops short of saying when NOT to use it versus prepare_physical_proof or the other prepare_* sibling tools.

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?