vealth

Submit the signed posting (step 2 of 2)

submit_post_work

Complete the posting: pass BODY_JSON from prepare_post_work UNCHANGED, the creator wallet's signature over MESSAGE_TO_SIGN, and (unless you hold an EWP key) xPayment — the standard X-PAYMENT header value your own wallet produced for the $0.05 write fee. If you send no payment, the answer is the live 402 challenge with exact price and pay-to; pay it from your own wallet and retry with a fresh prepare. This server relays to the same public gate any HTTP client uses — it holds no keys and no funds. Success returns your packet's id and public page; claiming it (even yourself) is free. Cost and signer: $0.05 for the post (claiming it stays free), paid and signed by the person's own wallet, and the house never holds a key.

Input Schema

Name	Required	Description
`bodyJson`	Yes	The exact BODY_JSON string from prepare_post_work, unchanged.
`xPayment`	No	Optional: the X-PAYMENT header value (EIP-3009 USDC on Base, from YOUR wallet) settling the $0.05 write fee. Omit if you hold an EWP key.
`signature`	Yes	The 0x… personal_sign output over MESSAGE_TO_SIGN, from the creator wallet.

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"
+}

AddedAug 11, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare openWorld and non-idempotent; the description adds substantial context beyond them: the server holds no keys or funds, it relays to the same public gate any HTTP client uses, an unpaid call returns a live 402 challenge, and success returns a packet id and public page. It also discloses the $0.05 fee and that claiming remains free.

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 instruction (pass BODY_JSON unchanged) is front-loaded, but the closing sentence repeats points already made: the $0.05 cost, wallet-paid signing, and the house holding no keys are stated twice in near-identical wording. It is padded rather than tight.

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 a paid, two-step write tool with an output schema present, the description covers the payment flow, the retry path on 402, custody guarantees, and the EWP-key exception. An agent has everything needed to invoke it 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?

Schema description coverage is 100%, so the schema already documents all three parameters, and the description largely restates them (BODY_JSON unchanged, signature over MESSAGE_TO_SIGN, xPayment header). It adds modest emphasis on the 'unchanged' constraint and the EWP-key exception, but nothing the schema lacks syntactically.

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?

States a specific verb (complete the posting) and names the resource (the work post packet) plus its exact position in a two-step flow. It explicitly names the sibling prepare_post_work as the source of bodyJson, so an agent can distinguish this submit tool from the many 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 Guidelines5/5

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

Gives explicit when-to-use (after prepare_post_work, passing BODY_JSON unchanged), a conditional alternative (skip xPayment if you hold an EWP key), and a failure path (a 402 challenge with exact price and pay-to, then retry via a fresh prepare). No inference about sequencing or payment is left to the agent.

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?