vealth

Accept the hours somebody worked (step 1 of 2)

prepare_accept_hours

Read-onlyIdempotent

You were named on a work packet as the person who accepts its hours: this is how you do that. FREE and KEYLESS, a signed judgment, no fee, no gas. NOBODY PAYS ANYBODY HERE: accepting hours releases no wage, records no settlement and mints nothing, it writes onto the record that those hours were worked and stops. THE HOUSE CANNOT ACCEPT ITS OWN HOURS, which is the whole reason this door exists: a house wallet is refused here, and so is the packet's own worker, because nobody grades their own exam. The signature is YOUR OWN, from the wallet the packet named, and nobody else's signature will open it. The worker states the hours; you decide the accepted figure, and a figure above their own claim needs allowAboveClaim. Read the proof first with get_work_packet. Returns MESSAGE_TO_SIGN and BODY_JSON; sign with that wallet's personal_sign, then call submit_accept_hours within 5 minutes. Once a packet names you, YOU ALONE DECIDE its proof: the house and the poster cannot approve or reject it. To return the proof instead, pass decision "reject" with a reason; the worker gets the reason and may resubmit, free. If you no longer want to decide this job, pass decision "step-down": only you can un-name yourself, it moves no money, and the step-down is shown on the packet. 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
`note`	No	Optional, up to 300 characters: one plain sentence saying what you checked.
`reason`	No	Required when decision is reject: one plain sentence saying what the worker must fix.
`workId`	Yes	The packet id whose hours you are accepting.
`acceptor`	Yes	Your 0x address, the one this packet named as its acceptor. Address only, never a private key.
`decision`	No	accept (the default), reject: return the proof to the worker with your reason, or step-down: stop being this packet's acceptor.
`hoursAccepted`	No	The hours you actually stand behind, greater than zero and at most 168. Not the hours claimed unless you agree with them.
`allowAboveClaim`	No	Only when you mean to credit MORE hours than the worker asked for. Default false, and a higher figure is refused without it.

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.

Changed3 schema fields changedNov 1, 2026

addedInput schema / properties / decision

Added value: +{
+  "description": "accept (the default), reject: return the proof to the worker with your reason, or step-down: stop being this packet's acceptor.",
+  "enum": [
+    "accept",
+    "reject",
+    "step-down"
+  ],
+  "type": "string"
+}

addedInput schema / properties / reason

Added value: +{
+  "description": "Required when decision is reject: one plain sentence saying what the worker must fix.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "workId",
-  "acceptor",
-  "hoursAccepted"
-]New value: +[
+  "workId",
+  "acceptor"
+]

AddedSep 8, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Rich disclosure beyond annotations: no fee, no gas, no wage released, no settlement, no minting, signature must come from the named wallet, and a five-minute signing window. The one tension is the phrasing 'it writes onto the record that those hours were worked' against readOnlyHint=true — the two-step explanation (returns MESSAGE_TO_SIGN, then submit) resolves it, but an agent skimming could briefly read this call as a state mutation.

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-loaded and purposeful in the first sentences, but the cost/signer facts are stated twice ('FREE and KEYLESS, a signed judgment, no fee, no gas' and again as 'Cost and signer: free, no gas'), and the all-caps rhetorical lines ('THE HOUSE CANNOT ACCEPT ITS OWN HOURS', 'nobody grades their own exam') inflate length without adding callable detail.

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?

Covers everything an agent needs before invoking: who may call, prerequisites, the follow-up submit step and its 5-minute deadline, the meaning of each decision, and the failure modes (wrong signer, house wallet, above-claim figure). With an output schema present, the return values (MESSAGE_TO_SIGN, BODY_JSON) are still noted, which is sufficient.

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 baseline is 3; the description still adds decision semantics ('reject' returns the proof with a reason, 'step-down' un-names only yourself) and the relationship between the worker's claim and hoursAccepted/allowAboveClaim. It does not elaborate workId, acceptor, or note, which the schema already handles.

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+resource (accept a work packet's hours) and its role in a two-step flow, and names both neighbors it interacts with: get_work_packet to read the proof and submit_accept_hours to finalize. It also defines the actor precisely ('you were named on a work packet as the person who accepts its hours'), so the agent can tell this apart from the many other prepare_* siblings.

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 an explicit ordered workflow: read the proof first with get_work_packet, call this, sign with the named wallet, then submit within 5 minutes. It also states the alternative branches with their conditions: decision 'reject' plus a reason (worker may resubmit free) versus 'step-down' to un-name yourself, plus when allowAboveClaim is needed. Exclusions are explicit too — house wallets and the packet's own worker are refused.

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?