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). Read-only: this quotes, it charges nothing and marks nothing funded. Call prepare_funding next to actually pay.

Input Schema

TableJSON Schema

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

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

TDQS

A4.6/5.0

Behavior5/5

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

The description goes well beyond the annotations by explaining that the quote is read from the board, never from caller input, that it reflects the outstanding obligation, and that a refusal comes in the board's own words. It also explicitly states 'this quotes, it charges nothing and marks nothing funded,' which aligns with and reinforces the readOnlyHint/idempotentHint annotations.

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 front-loaded with the core purpose and audience, then adds necessary behavioral caveats and a next-step pointer. It is somewhat long, but nearly every sentence adds important context about quote accuracy, partial funding, refusals, and read-only behavior, so the length 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?

Given that this tool has one optional parameter, a rich output schema, and strong annotations, the description is amply complete. It covers edge cases like partially funded packets, explicit premiums, stale wage quotes, refusal wording, and the distinction between quoting and funding, leaving no important ambiguity for an agent.

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%, so the schema already documents the single optional workId parameter and the omission behavior. The description reinforces the semantics but adds little beyond the schema for this tool; the partial-funding and premium details mostly apply to prepare_funding rather than funding_quote's own parameters.

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 names a specific verb ('quote'), a specific resource ('board packet'), and an explicit audience ('BUYER, not a worker'), immediately distinguishing this from worker-side tools. It also clarifies that this tool only asks about funding and cost, not performs funding, which separates it clearly from prepare_funding.

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 this tool is appropriate: a buyer wanting to know whether a packet can be funded and at what current cost. It directly names the next action ('Call prepare_funding next to actually pay') and excludes workers from its intended audience, giving clear routing guidance.

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?