vealth

Vote for or against a work packet (step 1 of 2)

prepare_vote

Read-onlyIdempotent

Say a job should matter more or less. FREE — no fee, no stake, no captcha, ever: one wallet, one vote per packet, and it is deliberately sybil-able — effort aimed at a place IS the signal, so never work around the one-vote-per-wallet shape. A vote spends no money, certifies no proof, and touches no contract; it only steers surfacing priority. Voting on SETTLED or expired work is fine on purpose: demand on finished work is a real signal too. Returns MESSAGE_TO_SIGN and BODY_JSON. Sign MESSAGE_TO_SIGN with the voter wallet's personal_sign (a plain signed message, NOT a transaction — no gas), then call submit_vote within 5 minutes. Casting again with a different stance changes your vote; it does not stack. 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
`reason`	No	Optional, up to 280 characters, shown on the public tally.
`stance`	Yes	Your position on this packet.
`workId`	Yes	The packet id, from find_work.
`voterKind`	No	Self-declared attribution so agent demand is never shown as human community consensus. Defaults to human if omitted.
`voterWallet`	Yes	The 0x… address that will sign and own this vote.

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 14, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses that voting is free, sybil-able by design, touches no contract, spends no money, and does not certify proofs. It also explains the signing flow, 5-minute submit window, non-transaction personal_sign requirement, and that the house never holds a key.

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 dense but front-loads the core vote behavior and signing flow, with each section generally earning its place. It repeats the 'free / no fee / no gas' point more than once, which is useful emphasis but slightly redundant.

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 tool with an output schema, it still explains the returned MESSAGE_TO_SIGN and BODY_JSON usage, the required personal_sign flow, the submit_vote follow-up, and the 5-minute deadline. It also covers the unusual sybil-ability and settled-work voting semantics, leaving little ambiguity for an agent.

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?

Schema coverage is already 100%, so the schema documents the five parameters. The description adds useful semantics around stance and voterWallet by explaining one-vote-per-wallet behavior, recasting changing the vote rather than stacking, and that the voter wallet signs the result.

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?

The definition makes clear this is the first step of casting a vote on a work packet, returning a message to sign before calling submit_vote. The opening sentence ('Say a job should matter more or less') is less precise than the rest, but the surrounding text and step-1-of-2 framing distinguish it from submit_vote.

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?

It gives concrete conditions: one wallet gets one vote per packet, voting on settled or expired work is acceptable, and casting again with a different stance changes rather than stacks the vote. It also names submit_vote as the required second step within 5 minutes, though it does not mention prepare_vote_withdraw as an alternative path.

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?