vealth

Provision a bounded packet of real ecological work

provision_work

Read-onlyIdempotent

Turn a place + problem (or a board packet id) into provisioned work: a bounded packet with scope, standards-registered method, proof requirement, tCO2e estimate, and the keyless funding path YOU pay from your own wallet. This tool returns the packet and the path; it never spends, never holds funds, never signs. When the retirement lane is running, approved proof queues a carbon retirement and an on-chain certificate — provision, not offset; that lane is paused by operator order since 2026-08-04. Cost and signer: free and keyless, nothing to sign.

Input Schema

Name	Required	Description
`query`	No	Or free text for the problem, e.g. 'storm drain' or 'tree planting'.
`workId`	No	Provision a specific open board packet by id (from find_work).
`latitude`	No	Center of the search, with query.
`radiusKm`	No	Search radius in km. Default 50.
`longitude`	No	Center of the search, with query.

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

First observedAug 2, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description states the operation never spends, holds funds, or signs, that it is free and keyless with no wallet signature required, and that the retirement lane has been paused by operator order since 2026-08-04. That paused-lane caveat is exactly the kind of operational context annotations cannot convey.

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?

Three sentences, front-loaded with the core transformation, then the safety guarantee, then the lane status and cost. The 'never spends / never signs' idea is restated in the final sentence ('keyless, nothing to sign'), which is minor redundancy but the overall density is justified.

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?

For a read-only, keyless provisioning tool with an output schema and full schema coverage, the description supplies everything an agent needs: what comes back, what it will not do, that it costs nothing, and that a downstream lane (retirement/certificate) is currently paused. No meaningful gaps remain.

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?

With 100% schema coverage the baseline is 3, but the description adds real meaning: it explains the two mutually alternative entry modes (geo query+coords vs workId packet reference) and ties workId to find_work as its source. It still does not clarify how multiple modes should be combined or which takes precedence.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete transformation (place + problem or board packet id → provisioned work packet) and enumerates exactly what the packet contains: scope, registered method, proof requirement, tCO2e estimate, funding path. It does not, however, explicitly contrast itself with nearby siblings like provision_plan, get_work_packet, or funding_quote, so an agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the two input modes ('place + problem' or 'a board packet id (from find_work)'), which tells the agent roughly when to reach for it. There is no explicit when-not or named alternative for overlapping tools such as get_work_packet or provision_plan, leaving the routing decision partly to inference.

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?