vealth

Prepare a free signed claim (step 1 of 2)

prepare_claim

Read-onlyIdempotent

Start claiming a packet for a wallet you control. Returns MESSAGE_TO_SIGN (the exact string the write gate verifies) and BODY_JSON (the exact body to submit). Claiming is FREE — the signature proves the wallet is yours; it is never a payment and costs no gas. Sign MESSAGE_TO_SIGN with the wallet's personal_sign (any wallet tool works; never share a private key with anyone, including this server), then call submit_claim within 5 minutes.

Input Schema

TableJSON Schema

Name	Required	Description
`crew`	No	Optional, for a MANAGER claiming for a crew: the people who will do the work, 1 to 25 of {"ref":"amina","label":"Amina"}. A ref is your own handle for the person (2 to 40 lowercase letters, digits or hyphens), a label an optional short name to call out; never an identity (no legal name, phone or email). This wallet stays the worker of record: it signs, hands in the proof and is paid. The crew rides inside the signed body; a bad crew is refused before any message to sign.
`workId`	Yes	The packet id, from find_work.
`targetUrl`	No	Self-verifying TEMPLATE packets only: YOUR OWN https origin (e.g. https://example.com). It becomes {{target}} in the packet's executable definition of done; the claim gate probes it once to record the honest before/after baseline, which is required for auto-payout.
`workerWallet`	Yes	The 0x… address that will sign and own this claim.
`attestAtLeast18`	No	Physical claims only. Set true ONLY after the human caller explicitly affirms: I am at least 18 years old. prepare_claim will refuse to create a signable claim when this statement is required and has not been affirmed.
`attestSafetyRead`	No	Hazard-bearing physical claims only. Set true ONLY after the human caller has actually read and affirms the exact packet safety / stop-work text that prepare_claim surfaces. Never infer or auto-fill this affirmation.

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 claiming for a crew: the people who will do the work, 1 to 25 of {\"ref\":\"amina\",\"label\":\"Amina\"}. A ref is your own handle for the person (2 to 40 lowercase letters, digits or hyphens), a label an optional short name to call out; never an identity (no legal name, phone or email). This wallet stays the worker of record: it signs, hands in the proof and is paid. The crew rides inside the signed body; a bad crew is refused before any message to sign.",
+  "items": {
+    "properties": {
+      "label": {
+        "type": "string"
+      },
+      "ref": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "ref"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changed2 schema fields changedSep 22, 2026

addedInput schema / properties / attestAtLeast18

Added value: +{
+  "description": "Physical claims only. Set true ONLY after the human caller explicitly affirms: I am at least 18 years old. prepare_claim will refuse to create a signable claim when this statement is required and has not been affirmed.",
+  "type": "boolean"
+}

addedInput schema / properties / attestSafetyRead

Added value: +{
+  "description": "Hazard-bearing physical claims only. Set true ONLY after the human caller has actually read and affirms the exact packet safety / stop-work text that prepare_claim surfaces. Never infer or auto-fill this affirmation.",
+  "type": "boolean"
+}

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 19, 2026

addedInput schema / properties / targetUrl

Added value: +{
+  "description": "Self-verifying TEMPLATE packets only: YOUR OWN https origin (e.g. https://example.com). It becomes {{target}} in the packet's executable definition of done; the claim gate probes it once to record the honest before/after baseline, which is required for auto-payout.",
+  "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/5.0

Behavior5/5

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

Beyond annotations, the description adds valuable behavioral context: claiming is free, the signature is never a payment, no gas is required, and there is a 5-minute validity window. It also includes a security warning about not sharing private keys. This meaningfully exceeds what readOnlyHint and idempotentHint already convey, and it does not contradict 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.

Conciseness5/5

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

The description is compact and front-loaded: purpose and outputs come first, then cost/security clarification, then the required next step and time limit. Each sentence earns its place without repetition or fluff.

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?

Given the rich input schema, output schema, and annotations, the description is complete for correct invocation. It covers the purpose, required next step, expiration, cost model, and security expectations, so an agent has everything needed to call the tool and proceed to submit_claim correctly.

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?

The schema description coverage is 100%, and the schema itself richly documents parameters like crew, targetUrl, attestAtLeast18, and attestSafetyRead. The description body adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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 description states a specific verb and resource: 'Start claiming a packet for a wallet you control' and clearly defines the tool's output as MESSAGE_TO_SIGN and BODY_JSON. The title adds 'step 1 of 2' and the description explicitly names submit_claim as the follow-up, which distinguishes it from sibling submit_* and prepare_* tools.

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 gives clear workflow context: sign MESSAGE_TO_SIGN with personal_sign and 'then call submit_claim within 5 minutes.' It also references find_work for the workId in the schema. However, it does not explicitly state when not to use this tool or name alternatives for merely viewing or inspecting work packets.

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?