vealth

Submit the signed site authorization (step 2 of 2)

submit_site_authorization

Complete the authorization: pass workId, the BODY_JSON from prepare_site_authorization UNCHANGED and the signature your wallet produced over MESSAGE_TO_SIGN. Relays to the same public door any HTTP client uses (POST /labor/work/:workId/site-authorization); this server holds no keys and no funds. Free with a valid signature from the poster or the wallet the poster named. The worker can then claim the job once a person has checked their credential; Vealth sends no email, so tell them. Cost and signer: free, no gas; signed by the person's own wallet or passkey, and the house never holds a key.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workId": "<workId>",
      "bodyJson": "<bodyJson>",
      "signature": "<signature>"
    },
    "name": "submit_site_authorization"
  }
}

Input Schema

Name	Required	Description
`workId`	Yes	The packet id, the same one prepare_site_authorization was given.
`bodyJson`	Yes	The exact BODY_JSON string from prepare_site_authorization, unchanged.
`signature`	Yes	The 0x… personal_sign output over MESSAGE_TO_SIGN.

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.

AddedNov 4, 2026

TDQS

A4/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses that the server is a pure relay holding no keys or funds, that the operation costs nothing and requires no gas, and that the signer is the person's own wallet or passkey. It also discloses the downstream consequence (worker can then claim once a credential is checked) and the absence of email notification. It does not say what happens on a failed or duplicated submission, which matters given idempotentHint=false.

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?

The opening sentence is well front-loaded with the required inputs and the ordering constraint. However, the cost and signer information is stated twice — 'Free with a valid signature...' and again 'Cost and signer: free, no gas; signed by the person's own wallet or passkey, and the house never holds a key' — and key custody is asserted twice, which wastes space in an otherwise dense description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and full parameter coverage, the description only needs to carry workflow, cost, and custody context, which it does. The remaining gap is failure/replay behavior for a non-idempotent submission, but the essentials for a correct call are all present.

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?

Schema description coverage is 100%, so all three parameters are already documented. The description only reinforces what the schema says (workId matches the prepare call, bodyJson must be byte-identical, signature is personal_sign output) without adding format or provenance detail beyond it. Baseline 3 applies.

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 states a specific verb and resource (complete/submit the site authorization) and immediately frames it as 'step 2 of 2' relative to prepare_site_authorization, so an agent can place it in the workflow without opening any schema. It also pins the exact resource path (POST /labor/work/:workId/site-authorization).

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 clearly establishes the precondition (must follow prepare_site_authorization, must reuse BODY_JSON unchanged, must have a wallet signature over MESSAGE_TO_SIGN) and who is eligible to sign (poster or the wallet the poster named). It stops short of naming an alternative for read-only checking (site_authorization_status) or stating what to do if the call is repeated.

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?