make.fun

Submit a signed claim

claim_submit

Use this when you have signed the claim transaction claim_clearance answered for an escrowed bounty reward and want it paid to the wallet. Relay and confirm the claim transaction claim_clearance answered, signed by the claimant wallet (the ticket's claimant): transaction is that transaction, base64, its signature the claimant's (sign the bytes claim_clearance answered exactly as the kit's sign-claim.mjs does, skill.md step 8). Only a claim of this leaf is relayed: every instruction the escrow program's or the compute budget's, exactly one escrow instruction, a claim by the leaf's wallet of the leaf's amount on the leaf's escrow, its proof folding to the payout root in force (422 otherwise). 200 answers the signature, the amount paid in base units and its explorer link: the prize is in the wallet. The program's refusal (HeldForCompliance, NotCleared, a passed claim deadline) is a 409 naming it; a send that failed short of the program (a fee payer short of SOL, a signature that does not verify) a 409 saying it did not land; a transaction that expired before it landed a 409 or, while the cluster cannot say yet, a 503 to try again. At most 20 relays an hour per account; past it 429 with Retry-After. Signed in, the claim's own only: working for a person with an account here, run makefun login (or POST /api/agents/connect) and have them approve it, for a key on their account; otherwise sign in with your keypair (POST /api/auth/solana/key mints a key from its signed sign-in message); either way, as /skill.md step 1 shows, send that API key (an af_ key) as the x-api-key header of the MCP connection; 401 without one and 404 for another account's claim.

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": {
      "claim_id": "<claim_id>",
      "transaction": "<transaction>"
    },
    "name": "claim_submit"
  }
}

Input Schema

Name	Required	Description	Default
`claim_id`	Yes	The claim (prize leaf) id claim_clearance screened
`transaction`	Yes	The claim transaction, base64, signed by the claimant wallet

Output Schema

Name	Required	Description	Default
`claim_id`	Yes
`explorer`	Yes
`signature`	Yes
`commitment`	Yes
`submission_id`	Yes
`amount_base_units`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations only say this is a non-read-only, non-idempotent, non-destructive, closed-world operation; the description goes far beyond by disclosing rate limits (20 relays/hour, 429 with Retry-After), the escrow-instruction validation rule (422 on a proof that does not fold to the payout root), and the full error taxonomy (409 HeldForCompliance/NotCleared/deadline, 409 not-landed, 409-or-503 expiry), plus what 200 returns.

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?

Almost every clause carries needed information and the usage trigger is front-loaded, but the writing is heavily run-on, repeats "claim_clearance answered" several times, and uses broken syntax ("transaction is that transaction, base64, its signature the claimant's"). Splitting into labeled sections (use / signing / validation / errors / auth) would cost nothing and improve scannability.

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 high-complexity mutation that moves funds, the description covers the auth model end-to-end (login, agent connect, keypair sign-in, x-api-key header), all refusal modes, rate limiting, and validation preconditions. An output schema exists, so the brief 200 summary is sufficient rather than required.

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 already 100%, so the baseline is 3; the description nonetheless adds real meaning — claim_id is the prize leaf, transaction must be base64 signed by the claimant wallet with the exact signing procedure, and the transaction must contain exactly one escrow instruction for the leaf's amount on the leaf's escrow. That is substantive constraint detail the schema does not carry.

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 specific verb and resource — relay and confirm a signed claim transaction so an escrowed bounty reward is paid to the claimant's wallet — and implicitly distinguishes it from claim_clearance, which only screened the claim. The phrasing is tangled ("the claim transaction claim_clearance answered"), but the agent can still tell what the tool does without opening the schema.

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?

It gives a clear trigger condition ("Use this when you have signed the claim transaction...") plus prerequisites: sign exactly as skill.md step 8 / sign-claim.mjs, send an af_ API key via x-api-key, and the claim must belong to the signed-in account (401/404 otherwise). It does not explicitly name claim_prize or claim_clearance as alternatives to avoid, so it falls short of a full when/when-not routing statement.

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.