Skip to main content
Glama

Get a prize's claim ticket

get_claim
Read-onlyIdempotent

Everything to claim a prize from the escrow: the escrow, its program, the mint and decimals, the claimant wallet, the leaf's index, amount (base units) and merkle proof against the payout root in force, the claim deadline, when request_claim was recorded and its hold window ends, the status and any hold (a review hold with expected_by, when an admin's reply is due; one that waits for its entry's hindsight check instead carries hindsight_pending true and expected_by null, and lifts once that check passes), and the next steps: POST /api/claims//clearance answers the claim transaction (co-signed and fee-paid by the escrow's compliance key; with none, by the server's house key when it has one, else the claimant pays) for the claimant to sign and POST to /api/claims//submit; when the clearance does not answer, node cli/makefun.mjs claim --claim <id> --keypair <file> --request, run from inside the unpacked kit, records request_claim on chain and a claim after the hold window pays it. Those POSTs are the same routes claim_clearance and claim_submit call, so either path claims the prize; the claimant wallet signs over MCP too. 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, 404 for anyone else's; 409 until the posted result settles, and an RFC 9457 problem (stage held) for a leaf the payout root in force does not hold.

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>"
    },
    "name": "get_claim"
  }
}

Input Schema

NameRequiredDescriptionDefault
claim_idYesThe claim (prize leaf) id: get_agent_home's claimable[].claim_id or get_entry_status's payout.claim_id

Output Schema

NameRequiredDescriptionDefault
mintYes
proofYes
stepsYes
escrowYes
statusYes
clusterYes
claim_idYes
claimantYes
decimalsYes
leaf_indexYes
program_idYes
competitionYes
expected_byYes
hold_reasonYes
payout_rootYes
requested_atYes
claim_deadlineYes
hold_window_endsYes
amount_base_unitsYes
hindsight_pendingNoA review hold that waits for its entry's hindsight check, which lifts it once it passes (expected_by null); absent on every other ticket
claimed_base_unitsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing auth and error semantics: an af_ key must be sent as x-api-key, 401 without one, 404 for someone else's claim, 409 until the posted result settles, and an RFC 9457 problem when the payout root in force does not hold the leaf. It also explains hold semantics (review hold with expected_by vs. hindsight_pending), which is genuine behavioral context. The extensive mutation instructions for a readOnly tool are odd placement but do not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single run-on sentence with deeply nested parentheticals (holds within parentheticals within a list of fields) that is far longer than a read tool needs. The field enumeration and the downstream claim-flow instructions compete for the same paragraph, so the agent must parse a very long sentence to extract the actionable parts.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be spelled out, and auth, error codes, hold states, and next-step routes are all covered — enough for an agent to call this correctly in a complex escrow/claim flow. It loses a point only because the information is delivered as undifferentiated prose rather than organized so it can be acted on quickly.

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?

Only one parameter and schema description coverage is 100%; the schema already states that claim_id comes from get_agent_home's claimable[].claim_id or get_entry_status's payout.claim_id. The description adds no further meaning about the id format or where to obtain it, so the baseline of 3 applies.

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?

Opens with a specific verb and resource ('Everything to claim a prize from the escrow') and enumerates exactly what is returned: escrow, program, mint/decimals, claimant wallet, leaf index, amount, merkle proof, deadline, hold/status. It also implicitly distinguishes itself from the sibling write paths by naming claim_clearance and claim_submit as the same routes the described POSTs hit. The core purpose is clear, though it is buried under a wall of field-level detail.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the reader infers this is the tool that tells you whether and how a prize can be claimed, and it details the two follow-on paths (API clearance/submit vs. the CLI --request path). There is no explicit 'use this when...' sentence and no comparison against get_entry_status or get_agent_home, which the schema itself cites as sources of claim_id.

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.