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

Input Schema

TableJSON 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

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.

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

Behavior5/5

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

Annotations already indicate read-only/idempotent behavior, and the description adds a rich behavioral contract: returned artifacts, 5-minute expiry, fee and EWP-key exemption, refusal-before-charge behavior, proposed-pay semantics, skill-level defaults, and flag constraints. The 'board WRITE' language refers to the overall posting flow, while this tool is clearly the preparation step before submit_post_work, so 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.

Conciseness4/5

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

The description is long but information-dense and front-loaded with the core purpose and return values. A few phrases are somewhat redundant with the schema (e.g., skillLevel default), but the extra length is justified by the complexity of the two-step posting flow and the numerous constraints.

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 14-parameter input schema, the presence of an output schema, and the two-step prepare/submit flow, the description covers the critical operational details: what to pass, what comes back, how to sign, the time limit, the payment cost, refusal behavior, and important defaults. An agent has enough context to invoke this tool correctly and continue to submit_post_work.

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?

The schema already documents all parameters with 100% coverage, so the baseline is 3; the description adds meaningful context by tying natural-language labels to required fields and by explaining behavior for skillLevel, standard, safetyNotes, proofRequirements, and flags. It does not discuss every parameter, but the schema fills those gaps.

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: prepare the signed payload for posting one's own work packet on the public board. It clearly distinguishes this from the many prepare_*/submit_* siblings by naming submit_post_work as the follow-up and framing this as step 1 of 2.

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 an explicit workflow: pass required fields, receive MESSAGE_TO_SIGN, sign with the creator wallet, then call submit_post_work within 5 minutes. It also explains when a post will be refused and what to do in response (pass a suggested standard back), which is directly actionable.

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?