Skip to main content
Glama

Record that you were paid in a VSH ecocredit (step 1 of 2)

prepare_credit_settlement
Read-onlyIdempotent

After your proof is approved and someone sent you VSH ecocredits on Regen Ledger: name the batch denom and the regen-1 transaction hash, and the board reads the transfer that reached the regen1 account YOUR signing key controls, then writes the same settlement record a dollar payout writes. Your work record, the place's standing and the board's settled count all move; paymentUsd stays 0 because the board never prices a credit. Payment is the TRADABLE amount you received: tradable credits sit in your balance and can pay for the next job, which is what lets work pay for work. Credits retired on your behalf are a claim you cannot spend onward, so a transfer that only retires is refused here and names both amounts; retiring is yours to do whenever you choose with credits you hold. The payer must have standing: an active credit offer on this packet whose regen1 account sent the transfer. FREE, no gas. Returns MESSAGE_TO_SIGN and BODY_JSON; sign with the worker wallet's personal_sign, then call submit_credit_settlement within 5 minutes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
txHashYesThe 64-character hex hash of the regen-1 transaction that paid you (no 0x prefix).
workIdYesThe packet you proved.
batchDenomYesThe Regen credit batch denom you were paid in, e.g. VSH01-001-20260907-20270907-001.
workerWalletYesThe 0x… address on the approved proof, the wallet that was paid and will sign.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okNo
toolNo
fundedNo
payUsdNo
workIdNo
claimIdNo
claimableNo
next_callNo
proofRuleNo
fulfillableByNo
definitionOfDoneNo
needs_from_callerNo
notClaimableReasonNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the read-only and idempotent annotations, the description discloses that the operation is free, returns a message to sign and body JSON, requires personal_sign, and must be followed by submit_credit_settlement within 5 minutes. It also clarifies the tradable-vs-retired distinction and the standing requirement.

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 purpose and then provides necessary operational details, but the first sentence is somewhat convoluted and the explanation of tradable vs. retired credits could be tightened. Overall it is dense but mostly earns its length.

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 the tool's complexity and the rich annotations/schema, the description covers all essential context: when to use it, what inputs matter, what conditions must hold, what it returns, how to sign, the next step, and the timeout. No critical usage information appears missing.

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?

The schema already provides solid descriptions for all four parameters, and the description adds meaningful context about tradable payments, the worker wallet that signs, and the type of transaction hash expected. This goes beyond the schema, though some added text is more about general settlement rules than individual 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 title and description clearly state that this tool prepares a credit settlement after proof approval and receipt of a VSH ecocredit payment. It also identifies the two-step flow by explicitly mentioning submit_credit_settlement as the follow-up, so an agent can understand the tool's role.

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 gives concrete conditions for use: proof approved, payment received as tradable credits, payer must have standing, and retired-only transfers are refused. It also explains the next action and the 5-minute validity window, leaving little ambiguity about when and how to invoke it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources