vealth

Can this packet be funded, and what would it cost

funding_quote

Read-onlyIdempotent

For a BUYER, not a worker: ask whether one board packet can be funded right now, and what funding it costs NOW. The quote is the packet's OUTSTANDING obligation — the board's posted wage minus verified contributions already recorded — read from the board, never from anything you send, so no caller can fund a $700 packet for $1 and no caller is quoted a stale full wage after others chipped in. Partial funding: when the host has chip-ins armed, any open packet also takes contributions from $0.01 up to what it still needs (contributeUsd on prepare_funding); an EXPLICIT amount above the remaining is recorded as a premium reserved for the worker — no default or omitted amount ever creates a premium. A refusal comes back in the board's own words (already funded, fully covered, claimed, settled, expired, no wage). While a door is open the quote carries the Vealth service fee (10% of the wage, shown apart) and the total; while paying Vealth is closed there is no fee. The worker is paid the full wage. Read-only: this quotes, it charges nothing and marks nothing funded. Next: prepare_funding where a Vealth door takes a payment; while paying Vealth is closed, the NEXT_CALL is prepare_direct_offer, a free signed offer to pay the worker directly. Cost and signer: free and keyless, nothing to sign.

Input Schema

Name	Required	Description	Default
`workId`	No	Optional packet id. Omit to quote the first open packet that still needs funding.

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"
+}
```

Changed3 schema fields changedAug 18, 2026

changedInput schema / properties / workId / description

Previous value: -"The packet id, from find_work."New value: +"Optional packet id. Omit to quote the first open packet that still needs funding."

removedInput schema / required
```
Removed value: -[
-  "workId"
-]
```

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

TDQS

A4.6/5.0

Behavior5/5

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

Far exceeds the readOnly/idempotent annotations: it explains the quote is the board's outstanding obligation read from the board, that partial funding accepts $0.01–remaining while an explicit overage becomes a worker premium (never a default), and enumerates refusal reasons (already funded, claimed, settled, expired, no wage). It also discloses fee behavior conditional on the Vealth door being open and notes the call is free and keyless.

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?

Front-loads the audience and core question, then sequences funding mechanics, refusals, fees, and next steps. Some clauses are illustrative padding ('no caller can fund a $700 packet for $1'), but nearly every sentence carries operational meaning.

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 an output schema exists (return values needn't be explained), the description still covers pricing composition, partial-fill rules, refusal messaging, fee conditions, and the required follow-up tool — everything an agent needs to call this correctly and route afterward.

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 coverage is 100% and the single optional workId is already documented as 'omit to quote the first open packet that still needs funding,' which the description largely restates. The description adds no new semantics for the id format or behavior when the id is unknown, so 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?

States a specific verb and resource ('ask whether one board packet can be funded right now, and what funding it costs NOW') and explicitly scopes the audience as a BUYER, not a worker. It also distinguishes the quote from the mutation siblings prepare_funding and prepare_direct_offer, so an agent can tell it apart without opening a schema.

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 explicit routing: 'Next: prepare_funding where a Vealth door takes a payment; while paying Vealth is closed, the NEXT_CALL is prepare_direct_offer.' It also states the read-only boundary ('this quotes, it charges nothing and marks nothing funded'), which is the when-not signal.

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?