Skip to main content
Glama

redeem_credits

MOVES MONEY: cash out a user's credits as a Stripe transfer to a connected account. Deducts amount credits and pays amount × the credit type's exchange_rate (USD per credit; the rate cannot be overridden). The credit type must be redeemable (else 400 NOT_REDEEMABLE). destination must be this user's own account from onboard_payout_account (else 400 INVALID_DESTINATION). Pass idempotency_key: a retry with the same key returns the first result (idempotent_replay: true) and never deducts or pays twice; without one, reference_id is the key, and with neither every call redeems again. 502 PAYOUT_PENDING means Stripe's answer was lost: retry with the SAME key (idempotency_key in the error) to finish it — if nobody retries, the reconciliation sweep settles it after ~15 minutes (paid, or credits returned only if Stripe definitely refused); a claim it cannot settle safely is flagged for manual review. Errors: 400 INSUFFICIENT_CREDITS, 400 PAYOUT_TOO_SMALL, 404 USER_NOT_FOUND, 402 STRIPE_TRANSFER_FAILED (credits restored), 409 IDEMPOTENCY_KEY_REUSED. Costs 1 CRD (platform credit) per call, charged even when the call is then rejected (a 429 RATE_LIMITED costs nothing). Error results include request_id; quote it to support.

Input Schema

NameRequiredDescriptionDefault
amountYesCredits to redeem
reasonNoReason, shown on the transfer and ledger
api_keyNoCred API key (optional if set via the x-api-key header)
user_idNoExternal user ID
currencyNoPayout currency (default usd)
metadataNoString key/values added to the Stripe transfer metadata
project_idNoCred project ID (optional; the API key already identifies the project)
user_emailNoUser email (alternative)
destinationYesStripe connected account ID (acct_…) that receives the payout
reference_idNoYour reference, stored on the transfer and ledger
x402_paymentNoBase64 x402 PaymentPayload, only when a previous call failed with an x402 PaymentRequired because the account is out of CRD
credit_type_idYesRedeemable credit type
idempotency_keyNoUnique key for this redemption (max 255 chars). Retrying with the same key and same arguments returns the first result instead of repeating it; reusing it for different arguments fails with 409 IDEMPOTENCY_KEY_REUSED. Generate a fresh key (e.g. a UUID) per intended operation and reuse it only to retry that operation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: exchange-rate mechanics that cannot be overridden, exactly what idempotency does (including the fallback where reference_id becomes the key and the case where neither exists so every call redeems again), the 502 PAYOUT_PENDING recovery path with the ~15 minute reconciliation sweep, and the 1 CRD per-call cost that is charged even on rejection while a 429 is free.

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-loaded with the critical "MOVES MONEY" warning and organized around prerequisites, idempotency, recovery, and errors. It is dense and near run-on in the middle sentence, but essentially every clause carries operational information an agent needs before calling.

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 13-parameter money-movement tool with no annotations and no output schema, the description covers prerequisites, idempotency, failure recovery, cost model, and the full error taxonomy, which is as complete as an agent needs to invoke it safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline would be 3, but the description adds real meaning beyond the schema: the fixed exchange rate for `amount`, the restriction that `destination` must be the user's own onboarded account, and the non-obvious interaction between `idempotency_key`, `reference_id`, and repeat redemptions.

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?

Opens with a specific verb and resource - "cash out a user's credits as a Stripe transfer to a connected account" - and immediately signals the money-moving nature. It is clearly distinguishable from sibling read/write tools like deduct_credits, refund_credits, issue_credits, and onboard_payout_account, which the destination constraint explicitly references.

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?

Prerequisites are stated concretely: the credit type must be redeemable, destination must be this user's own account from onboard_payout_account, and idempotency_key should be a fresh UUID per intended operation. It stops short of an explicit "use X instead when Y" comparison against siblings such as deduct_credits or refund_credits, leaving that routing to inference.

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