make.fun

Withdraw a deposit

proposal_withdraw

Take your deposit back before the decision: answers a close_proposal transaction (base64, legacy, signed by nobody yet) for your wallet to sign, as its authority and fee payer, and send to the cluster itself before it passes last_valid_block_height; it returns the whole vault to the wallet's token account (sponsor_token_account) and both rents to the wallet, and the chain sync then records the proposal withdrawn. node cli/makefun.mjs sponsor withdraw --proposal <id> --keypair <file>, run from inside an unpacked kit, signs and sends it. Refused with no deposit on chain or once decided (409), under the escrow's payout stop (503) and while the wallet is held on chain (451). Signed in only, your own proposals: 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; without one it answers 401, and another account's proposal 404.

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": {
      "proposal_id": "<proposal_id>"
    },
    "name": "proposal_withdraw"
  }
}

Input Schema

Name	Required	Description	Default
`proposal_id`	Yes	The proposal's id (a UUID): proposal_create answers it as id; GET /api/sponsor/proposals lists yours

Output Schema

Name	Required	Description	Default
`why`	Yes
`proposal`	Yes
`fee_payer`	Yes
`proposal_id`	Yes
`transaction`	Yes
`vault_base_units`	Yes
`sponsor_token_account`	Yes
`last_valid_block_height`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.3/5.0

Behavior5/5

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

The annotations only flag readOnly=false, destructive=false and idempotent=false; the description goes well beyond them by disclosing the actual fund movement (the whole vault back to sponsor_token_account, both rents to the wallet), the pre-signature nature of the transaction, the last_valid_block_height deadline, and the full 401/404/409/451/503 refusal matrix. Nothing here contradicts the annotations – returning the caller's own deposit is consistent with destructiveHint=false.

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?

Purpose is front-loaded, but the body is a chain of very long compound sentences that cram transaction mechanics, fund flows, CLI usage, auth onboarding and five HTTP status codes together. Every element is relevant, but the auth walkthrough (login, POST /api/auth/solana/key, x-api-key header) could be compressed or separated without loss.

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?

An output schema exists, so return values need not be explained, and the description covers everything else an agent needs: authentication path (af_ key in x-api-key), ownership scope (your own proposals only), failure modes, and the sign-and-send sequence with its expiry condition. Nothing required to invoke it correctly is missing.

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?

Schema coverage is 100% and the single proposal_id parameter is already described as a UUID with sourcing hints, so the schema carries the load. The description only echoes it as '--proposal <id>' in the CLI example, adding no new meaning beyond format or provenance.

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 opening clause 'Take your deposit back before the decision' states a specific verb (withdraw) and resource (deposit) plus a timing scope, and the follow-up makes clear it produces a close_proposal transaction for the wallet to sign. It does not name the inverse sibling (proposal_deposit) explicitly, so the differentiation is inferable rather than stated.

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?

Both the when and the when-not are spelled out: it is for pre-decision withdrawal, and it is 'Refused with no deposit on chain or once decided (409), under the escrow's payout stop (503) and while the wallet is held on chain (451)'. It also names the concrete alternative surface (the makefun CLI withdraw command) so an agent knows another path exists.

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.