vealth

Offer your own price on a work packet (step 1 of 2)

prepare_bid

Read-onlyIdempotent

Name your price instead of claiming at the posted pay. FREE — a signed offer, no fee, no gas. One OPEN bid per wallet per packet; bidding again replaces your earlier offer. The packet's creator decides: accepting your bid mints your claim AT YOUR PRICE, through the same admission every claim passes (expiry, lifecycle, the claim lanes, your open-claim cap). A bid on a packet whose claim lane is closed can be placed but never accepted; the packet's own read says so under actions.bid.note. A bid is a deferred claim, so a physical packet asks the bidder's human for the same statements a claim does (attestAtLeast18, and attestSafetyRead where the packet names its own hazards); the first call surfaces the exact wording and refuses to make a signable offer until each is affirmed. Returns MESSAGE_TO_SIGN and BODY_JSON; sign with the bidder wallet's personal_sign, then call submit_bid within 5 minutes. 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
`workId`	Yes	The packet id, from find_work.
`amountUsd`	Yes	Your price in USD, greater than zero.
`bidderKind`	No	Self-declared attribution. Defaults to agent if omitted.
`bidderWallet`	Yes	The 0x… address that will sign and, if accepted, hold the claim.
`attestAtLeast18`	No	Physical bids only. Set true ONLY after the human caller explicitly affirms: I am at least 18 years old. A bid is a deferred claim, so prepare_bid will refuse to create a signable bid when this statement is required and has not been affirmed.
`attestSafetyRead`	No	Hazard-bearing physical bids only. Set true ONLY after the human caller has actually read and affirms the exact packet safety / stop-work text that prepare_bid surfaces. Never infer or auto-fill this affirmation.

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 changedOct 22, 2026

addedInput schema / properties / attestAtLeast18

Added value: +{
+  "description": "Physical bids only. Set true ONLY after the human caller explicitly affirms: I am at least 18 years old. A bid is a deferred claim, so prepare_bid will refuse to create a signable bid when this statement is required and has not been affirmed.",
+  "type": "boolean"
+}

addedInput schema / properties / attestSafetyRead

Added value: +{
+  "description": "Hazard-bearing physical bids only. Set true ONLY after the human caller has actually read and affirms the exact packet safety / stop-work text that prepare_bid surfaces. Never infer or auto-fill this affirmation.",
+  "type": "boolean"
+}

AddedSep 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well beyond annotations: free, no gas, no fee, house never holds a key, one open bid per wallet with replacement, the creator's acceptance mints the claim at bidder's price through normal admission checks, and the attestation refusal on first call. Minor tension: readOnlyHint=true vs 'bidding again replaces your earlier offer' implies persisted bid state, though the tool itself only produces a signable message, so it is not a true contradiction.

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?

Dense but front-loaded: the core value proposition and cost come first, then rules, then the sign/submit handoff. It is on the long side and packs several clauses per sentence, but nearly every clause carries operational information an agent needs.

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?

Complete for a two-step prepare flow: it names the return fields (MESSAGE_TO_SIGN, BODY_JSON), the signing method and signer, the 5-minute submit window, the submit_bid follow-up, and the conditions under which it refuses. Output schema exists, so no further return-value detail is needed.

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 100% so the baseline is already met, but the description adds real meaning: amountUsd becomes the minted claim price on acceptance, bidderWallet is the wallet that signs via personal_sign, and the two attestation flags gate whether a signable offer is produced at all. Only bidderKind is left entirely to the schema.

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?

Opens with a specific verb+resource and an explicit contrast: 'Name your price instead of claiming at the posted pay,' which distinguishes prepare_bid from prepare_claim in the sibling list. The title reinforces the two-step flow (step 1 of 2), so an agent knows this is the offer-creation half.

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?

Explicitly frames the choice as bid-vs-claim, states the one-open-bid-per-wallet rule, warns that bids on closed claim lanes can be placed but never accepted, and hands off to submit_bid within 5 minutes. That is when-to-use, when-not-to-expect-acceptance, and the required follow-up call all in one place.

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?