vealth

Post your own work packet (step 1 of 2)

prepare_post_work

Read-onlyIdempotent

Put work YOU define on the public board — your place, your problem, your terms. Pass the creator wallet, a title, what needs doing, where, and the proposed pay. Returns MESSAGE_TO_SIGN (proving the creator wallet is yours) and BODY_JSON. Posting is a board WRITE: it costs $0.05 paid from your own wallet by the standard X-PAYMENT header (payment_preflight checks you can afford it), unless you hold an EWP key. The pay you propose stays PROPOSED until someone funds it — approved proof on an unfunded packet earns provable credit rather than cash, and the packet says which before anyone claims. Sign MESSAGE_TO_SIGN with the creator wallet's personal_sign, then call submit_post_work within 5 minutes. The board carries only work with a home in the Vealth Standard and a documented method: a post that names neither is refused before any charge, and the refusal lists the nearest documented standards; pass one back as standard. Say who can do it (skillLevel; omitted, it posts as entry), its hazards (safetyNotes), its proof items (proofRequirements) and any permit or licensed trade it needs (flags). Cost and signer: free to prepare; submitting costs $0.05, paid and signed by the person's own wallet, and the house never holds a key.

Input Schema

Name	Required	Description
`flags`	No	Optional authority flags, the two the claim gate reads and no others: permit-required when the work needs a permit, regulated when it needs a licensed trade (licensed electrician, plumber or contractor, asbestos or lead abatement). The board records the need and keeps such work closed to claims while regulated claims are closed; never leave a flag off to make work claimable.
`title`	Yes	Short honest title, e.g. 'Monthly care and growth check, planted neem tree'.
`location`	Yes	Where the work is: address or place name. Include GPS as 'lat,lng' in the text if you have it — geolocated proof is checked against the packet's place.
`standard`	No	Optional. The documented standard this work serves (a snake_case id such as 'tree_planting_establishment'); when a refusal lists suggestedStandards, pass one of them here. Omit it and the board lands the title on a documented standard itself when the title is that work's name.
`workType`	No	0 = water, 1 = soil/land/planting, 2 = building/structure. Trees are 1.
`proofRule`	No	What proof completes the work, e.g. 'GPS pin + photo of the tree next to a measuring stick + watering confirmation'.
`skillLevel`	No	Optional. Who can do this work: entry (a newcomer, safely, from the text alone), intermediate or advanced. Omitted, it posts as entry and the reply says so; the board's entry-level filter reads it, so never leave skilled work at the default.
`description`	Yes	What needs doing, concretely — a stranger (or the poster themselves) should be able to do it from this text alone.
`safetyNotes`	No	Optional. The hazards and stop-work rules a worker must read before starting, at most 600 characters. A packet with safety notes asks every claimer to affirm they are 18 or over and have read this exact text.
`creatorWallet`	Yes	The 0x… address posting this work. It signs, and it owns the posting.
`expiresInDays`	No	Days the packet stays open. Default 30.
`workTypeLabel`	No	Optional. A documented work type (snake_case) when you know the board's own name for the work.
`proposedPayUsd`	Yes	Proposed pay in USD. Proposed, not promised: unfunded packets settle as provable credit.
`proofRequirements`	No	Optional. The proof items, one line each (at most 20, 600 characters each), e.g. 'photo of the tree beside a measuring stick'.

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.

Changed4 schema fields changedSep 23, 2026

addedInput schema / properties / flags

Added value: +{
+  "description": "Optional authority flags, the two the claim gate reads and no others: permit-required when the work needs a permit, regulated when it needs a licensed trade (licensed electrician, plumber or contractor, asbestos or lead abatement). The board records the need and keeps such work closed to claims while regulated claims are closed; never leave a flag off to make work claimable.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / proofRequirements

Added value: +{
+  "description": "Optional. The proof items, one line each (at most 20, 600 characters each), e.g. 'photo of the tree beside a measuring stick'.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / safetyNotes

Added value: +{
+  "description": "Optional. The hazards and stop-work rules a worker must read before starting, at most 600 characters. A packet with safety notes asks every claimer to affirm they are 18 or over and have read this exact text.",
+  "type": "string"
+}

addedInput schema / properties / skillLevel

Added value: +{
+  "description": "Optional. Who can do this work: entry (a newcomer, safely, from the text alone), intermediate or advanced. Omitted, it posts as entry and the reply says so; the board's entry-level filter reads it, so never leave skilled work at the default.",
+  "enum": [
+    "entry",
+    "intermediate",
+    "advanced"
+  ],
+  "type": "string"
+}

Changed2 schema fields changedSep 8, 2026

addedInput schema / properties / standard

Added value: +{
+  "description": "Optional. The documented standard this work serves (a snake_case id such as 'tree_planting_establishment'); when a refusal lists suggestedStandards, pass one of them here. Omit it and the board lands the title on a documented standard itself when the title is that work's name.",
+  "type": "string"
+}

addedInput schema / properties / workTypeLabel

Added value: +{
+  "description": "Optional. A documented work type (snake_case) when you know the board's own name for the work.",
+  "type": "string"
+}

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

Behavior5/5

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

Adds rich behavioral context beyond annotations: free to prepare, returns MESSAGE_TO_SIGN and BODY_JSON, $0.05 submission cost via X-PAYMENT unless holding an EWP key, proposed pay settles as credit if unfunded, and refusals occur before any charge. It also discloses that the house never holds a key and spells out the 5-minute signing window.

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?

Front-loads purpose and workflow well, but is long and contains redundancy — the $0.05 cost and 'own wallet' point appear twice ("Posting is a board WRITE..." and "Cost and signer: free to prepare; submitting costs $0.05"). The density is somewhat justified by the payment/signature flow, but it could be tightened.

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?

For a 14-parameter tool with full schema coverage, output schema, and annotations, the description covers the entire prepare→sign→submit flow, cost, timing, and error handling, so an agent has what it needs to call it correctly. Any remaining gaps (e.g., exact return shape) are handled by the output schema.

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?

With 100% schema coverage the schema already documents every field, and the description reinforces key semantics — skillLevel defaulting to entry, flags being permit/regulated, safetyNotes and proofRequirements — mapping the important inputs to their meaning. Much of this repeats the schema rather than adding new format/syntax detail, so it sits at a solid 4 rather than 5.

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?

States a specific verb and resource ("Put work YOU define on the public board") and clearly frames this as a preparation step that returns MESSAGE_TO_SIGN and BODY_JSON, with the title noting "step 1 of 2". The opening line slightly overstates the tool as putting work on the board, but the explicit "then call submit_post_work" and "free to prepare" clarify the two-step split from its sibling.

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?

Gives clear workflow guidance: pass the five fields, sign MESSAGE_TO_SIGN with the wallet's personal_sign, then call submit_post_work within 5 minutes. It also states the constraint that the board only carries work with a documented standard/method, and what to do when refused (pass one back as `standard`). It stops short of explicit 'when not to use' exclusions, but the flow and routing to the next sibling are well covered.

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?