vealth

What everything here costs, before you pay for anything

payment_options

Read-onlyIdempotent

The whole price list for this server's paid doors, in dollars, cheapest first. Use it to budget BEFORE committing to a call — without it the only way to learn a price is to call a door and read the 402 it answers with. Prices are read from the live door manifest, never a hand-kept table, so a door that changes price cannot leave a stale number quoted here; the door's own 402 challenge remains the final price truth. Free, keyless, read-only. There is no balance to top up: you pay each call from your own wallet at the moment you call. Cost and signer: free and keyless, nothing to sign.

Input Schema

Name	Required	Description	Default
`maxUsd`	No	Optional ceiling — show only doors costing this much or less.

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

Changed1 schema field changedAug 18, 2026

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

TDQS

A4.2/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: discloses the data source (live door manifest vs. hand-kept table), the authority ordering (the 402 challenge is the final price truth), the fact there is no balance to top up, and that payment comes from the caller's own wallet at call time. These are exactly the traits an agent needs before deciding whether to trust the numbers.

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 with purpose and usage, but the free/keyless/read-only point is stated twice (mid-description and again in the trailing 'Cost and signer' sentence), and the manifest-vs-table rationale runs long. Tightening would remove real duplication.

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?

An output schema exists, so return values are covered structurally, and the description supplies the trust/freshness context an agent needs before relying on the list. Minor gap: no guidance on how this relates to the sibling quote tools (payment_preflight, credential_quote) it will likely be used alongside.

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 maxUsd parameter is fully described there, so the description needn't re-explain it. The only added semantic is the 'cheapest first' ordering, which is useful but minimal — baseline 3 fits.

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 resource (the full price list of paid doors, in dollars, ordered cheapest first) with a clear scope statement. An agent can tell this is a catalog/read tool rather than a quote or settlement tool without opening the schema.

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?

Explicitly says to use it to budget BEFORE committing to a call, and explains the fallback (calling a door and reading its 402). It doesn't name sibling tools like payment_preflight or credential_quote as alternatives, so routing among the quote-family tools is left implicit.

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?