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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.
`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'.
`description`	Yes	What needs doing, concretely — a stranger (or the poster themselves) should be able to do it from this text alone.
`creatorWallet`	Yes	The 0x… address posting this work. It signs, and it owns the posting.
`expiresInDays`	No	Days the packet stays open. Default 30.
`proposedPayUsd`	Yes	Proposed pay in USD. Proposed, not promised: unfunded packets settle as provable credit.

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

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover the read-only, non-destructive, idempotent safety profile. The description adds substantial context: the $0.05 cost via X-PAYMENT, the EWP exemption, proposed-vs-funded payment behavior, provable credit, and the 5-minute signing deadline. This goes well beyond what the annotations provide.

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 dense but every sentence earns its place: purpose, inputs, return values, cost, payment semantics, and next steps. It front-loads the workflow and keeps the most important operational details clear without filler.

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 prepare step, the description covers required inputs, output purpose, cost and payment auth, credit semantics, the exact next call, and a time limit. Combined with the output schema, no critical information 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?

All 8 parameters are already documented in the schema (100% coverage), so the baseline is 3. The description restates key inputs and adds context around proposed pay, but it does not materially expand on the parameter descriptions already present.

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 clearly states the tool prepares a post-work packet by returning MESSAGE_TO_SIGN and BODY_JSON, and it names the follow-up tool submit_post_work. The 'step 1 of 2' title plus the signing instructions remove ambiguity about whether this tool performs the actual posting.

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 creator wallet, title, description, location, and proposed pay; sign MESSAGE_TO_SIGN; then call submit_post_work within 5 minutes. This is actionable and leaves no doubt about when or how to use the tool.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation5/5

Despite 41 tools, each has a highly specific purpose with detailed descriptions that clearly differentiate them. The prepare_/submit_ pairs, domain-specific prefixes (gmx_, regen_), and distinct action types (find, get, verify, etc.) leave little room for confusion. Even closely related tools like funding_quote and prepare_funding or my_work and my_votes are explicitly distinguished.

Naming Consistency3/5

Naming conventions are mixed: some tools use plain nouns (account_statement, board_stats), others use verb_noun patterns (prepare_*, submit_*, get_*), possessive (my_votes, my_work), or descriptive phrases (how_to_claim, retire_and_certify). While not chaotic, the lack of a single consistent pattern reduces predictability. However, prefixes like gmx_ and regen_ provide internal consistency within subdomains.

Tool Count2/5

With 41 tools, the count significantly exceeds the recommended range (3-15) and falls into the 'too many' category (25+). Although the server covers a wide range of features (work lifecycle, Regen governance, GMX trading, anchoring, carbon), this number can overwhelm agents and make selection challenging. A more focused tool set would improve coherence.

Completeness4/5

The tool set covers the core workflows for its stated domains well: work posting/funding/claiming/proofing, Regen governance and token data, GMX position management, anchoring, and carbon estimation. Minor gaps exist (e.g., no GMX order cancellation, no work deletion), but overall the surface is comprehensive enough to accomplish primary use cases without dead ends.

Resources

Need Help?