vealth

Record that you were paid in a token (step 1 of 2)

prepare_token_settlement

Read-onlyIdempotent

After your proof is approved and someone paid you in a token on chain: name the chain (8453 Base or 4663 Robinhood Chain) and the transaction hash, and the board reads the transfer to YOUR wallet and writes the same settlement record a dollar payout writes — your work record, the place's standing and the board's settled count all move; paymentUsd stays 0 because the board never prices a group's token. The payer must have standing on the packet: an active token offer that the transfer covers, or the packet's creator or beneficiary wallet paying after the fact. A stranger's junk transfer settles nothing. Base USDC is refused here (that is the priced rail: /labor/settle). Your signature is your consent to the token as payment. FREE, no gas. Returns MESSAGE_TO_SIGN and BODY_JSON; sign with the worker wallet's personal_sign, then call submit_token_settlement within 5 minutes.

Input Schema

TableJSON Schema

Name	Required	Description
`txHash`	Yes	The 0x… hash of the transaction that paid you.
`workId`	Yes	The packet you proved.
`chainId`	Yes	8453 = Base, 4663 = Robinhood Chain.
`workerWallet`	Yes	The 0x… address on the approved proof — the wallet that was paid and will sign.

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. Dates show when Glama detected each change.

AddedSep 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

The description adds substantial behavior beyond the annotations: no gas cost, 5-minute expiry, paymentUsd stays 0, signature-as-consent, and payer standing requirements. The word 'writes' could initially suggest this call mutates state, but the closing sentence clarifies it only returns a signing payload; readOnlyHint is not directly contradicted, though the wording could be slightly clearer.

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 and front-loaded with the principal precondition, but it is written as long multi-clause sentences that are harder to parse than bullet points or short directives. Still, every sentence conveys necessary information; nothing is 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?

Given the output schema, fully documented parameters, and annotations, the description completes the picture: preconditions, allowed chains, payer standing, next step, timeout, gas, and semantic side effects. An agent has everything needed to select and invoke this tool correctly and hand off to submit_token_settlement.

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 baseline is 3. The description enriches the schema by tying each parameter to its semantic role in the flow: workerWallet is the paid wallet that must sign, txHash is the specific payment transfer, workId is the proved packet, and chainId names the two enums. It also adds the critical exclusion that Base USDC is not accepted here.

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 goes far beyond the tool name, stating the precise condition (approved proof + token payment), the required inputs (chainId and txHash), and the concrete output (MESSAGE_TO_SIGN and BODY_JSON for a two-step flow). It also distinguishes itself from submit_token_settlement and /labor/settle, making the tool's role unambiguous.

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?

The description explicitly states when to use this tool: after proof approval and an on-chain token payment, naming the allowed chains and then calling submit_token_settlement within 5 minutes. It also gives clear exclusions: Base USDC belongs on /labor/settle, and a stranger's junk transfer settles nothing. This is strong when/when-not guidance with named alternatives.

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?