make.fun

Claim your approved referral rewards

claim_referral_rewards

Claim every approved referral reward of your account at once, and every approved quest reward with them (get_referrals' claim.claimable_usd), in USDC on Solana, as POST /api/me/referrals/claim does: one claim of the whole approved total (no minimum), with the checks of a reward paid by transfer, unchanged: the claim form (method usdc-solana; destination, a Solana wallet; legal_name, country and tax_form only when get_referrals' claim.tax_details_required is true, ignored otherwise), the payout pin (when claim.pinned_destination is set, the destination must be it), autopay's switches and the automatic screen (the destination on the sanctions list, the declared country, the destination one of your account's wallets, the automatic cap). Answers the claim: paid in this call (tx_ref, explorer_url), sending (confirming on Solana), or held with its words until an admin pays it (the screen held it, or autopay is off or paused). A refusal is the route's answer whole: 400 at a field's path (a destination that is no Solana wallet, the tax details missing at the threshold, a destination other than your payout pin), 409 when neither an approved referral reward nor an approved quest reward waits to be claimed, or 451, the screen's RFC 9457 problem (claim_sanctions, claim_geo) with its checks and fix, nothing filed and your rewards still approved. Signed in only: send your account's API key (an af_ key) as the x-api-key header of the MCP connection; without one it answers 401.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "destination": "<destination>"
    },
    "name": "claim_referral_rewards"
  }
}

Input Schema

Name	Required	Description
`method`	No	usdc-solana, the one method (omitted, it is usdc-solana)
`country`	No	ISO 3166-1 alpha-2 country of residence, e.g. US: only when claim.tax_details_required
`tax_form`	No	W-9 for a US person, W-8BEN for everyone else: only when claim.tax_details_required
`legal_name`	No	Your legal name: only when claim.tax_details_required
`destination`	Yes	The Solana wallet (base58) the rewards are paid to in USDC: one of your wallets (get_referrals claim.wallets), or claim.pinned_destination when it is set

Output Schema

Name	Required	Description	Default
`claim`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations only mark this as a non-read-only, non-destructive, non-idempotent closed-world call; the description goes far beyond by disclosing payout mechanics (transfer, tx_ref, explorer_url), the pending 'sending' state, admin-held outcomes, and the automatic screen's checks (sanctions list, declared country, account wallets, automatic cap). It enumerates failure semantics with exact status codes and paths — 400, 409, 451 with RFC 9457 problem types claim_sanctions/claim_geo — and states that a refusal files nothing and leaves rewards approved. Authentication is spelled out too: an af_ key in x-api-key, 401 otherwise.

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?

The purpose is front-loaded, but the body is a single sprawling sentence with parenthetical piles (the claim form, the pin, autopay's switches, the screen) that is parseable only on a second read. Nearly every clause carries information, so it is not padded, yet the run-on structure and mid-sentence reference to 'POST /api/me/referrals/claim does' cost comprehension on a tool an agent must call precisely.

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 a 5-param schema with full coverage, an output schema, and annotations covering mutability, the description supplies everything else an agent needs: preconditions sourced from get_referrals, authentication requirements, the full matrix of success states, and status-code-level refusal handling. Nothing material for correct invocation appears to be 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?

Schema coverage is 100%, so the baseline is 3; the description earns above that by supplying the cross-field conditional logic the schema states only per-field — tax fields are all-or-nothing behind claim.tax_details_required, and destination is constrained to claim.wallets or the pinned destination, with a 400 when it differs from the pin. The remainder (method constant, base58 wallet) is already in the schema, so it is reinforcement rather than new meaning.

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?

States a specific verb and resource with precise scope: claims all approved referral rewards plus approved quest rewards, paid in USDC on Solana, mirroring POST /api/me/referrals/claim. The action and its breadth ('every approved... at once, no minimum') are unambiguous. It does not, however, distinguish itself from sibling claim_* tools such as claim_prize or claim_submit, so an agent must infer that those cover different reward classes.

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?

Gives concrete preconditions and conditional usage: the claim form fields (legal_name, country, tax_form) apply only when claim.tax_details_required is true and are 'ignored otherwise', the destination must equal claim.pinned_destination when set, and a 409 signals there is nothing to claim. This is clear context for calling it correctly. It stops short of naming an alternative route for the near-miss cases (e.g., what to use instead when rewards are held or unapproved).

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

All make.fun tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.