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

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

Behavior5/5

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

Beyond the annotations, the description explains exactly what is returned (MESSAGE_TO_SIGN and BODY_JSON), that the operation is free and non-payment, that gas is not required, that the signed message expires in 5 minutes, and that the house never holds a key. These details fill out the behavioral contract in a way the annotations alone do not.

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 action and immediately explains the return values and next step. It is slightly repetitive, however: the cost/signer facts appear twice ('Claiming is FREE...' and then 'Cost and signer: free, no gas...'), which dilutes conciseness without adding new information.

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 a 6-parameter tool with full schema coverage, annotations, and an output schema, the description supplies the remaining workflow context: what to do with the output, the 5-minute expiration, the signing method, and the security expectations. Nothing essential for correct invocation is missing.

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 every parameter already has a detailed description, so the schema carries the parameter semantics burden. The tool description does not add parameter-specific meaning beyond naming the two return values, which is appropriate given the rich schema.

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 explicitly frames itself as step 1 of 2, with the next step named as submit_claim. This makes the tool's role distinct from its obvious sibling submit_claim and from discovery tools like find_work.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use context and a precise continuation rule: 'then call submit_claim within 5 minutes.' It also identifies the signing requirement (personal_sign with the wallet's own key) and safety boundaries, leaving little room for incorrect use.

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?