make.fun

Start a proposal

proposal_create

Start a proposal of a competition you sponsor: a draft of the proposal as written, funded from wallet. It mints the 16-byte competition id the escrow's addresses derive from and an internal draft competition (never listed until approved). Answers the proposal (201): its id, stage draft, the competition it composes, and next_steps. A draft may still fail its checks: proposal_checks runs them, proposal_update edits it. A competition you sponsor takes no entry from you (the entry check sponsor_self_entry). 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; an account with no linked Solana wallet is refused 403.

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

Input Schema

Name	Required	Description	Default
`wallet`	No	The wallet that funds and signs the deposit: one linked to your account (base58); default its first
`proposal`	Yes	The SponsorProposal as you write it (JSON): version 1; competition {title, summary, description, rules, category, skills, duration_hours (how long entries stay open, in hours: 336 is two weeks)}, never a date: make.fun sets the opening, the deadline and the final window from duration_hours on every save and check, and replaces any you write; harness {template (a house scoring template: pumpfun-replay, solana-bars-1h, solana-clmm-lp; sponsor_templates lists the datasets, metrics, knobs and prize bar of each), dataset, metric, and its bounded knobs}, or, when no template fits, scoring {custom: {brief (what wins and how to judge it, in plain words), examples, kind?, runtimes?}} instead (it funds first: proposal_deposit once its checks but the template's pass, and the make.fun team sets up how it is scored while it is in review); a code bounty, judged on hidden tests make.fun writes, is always such a brief, with kind one of code-score, code-first, code-smallest, code-fastest, code-cheapest and its runtimes (sponsor_templates' code_brief says how to write it); submission_rule {max_per_day, max_total, strategy_note_required}; prizes [{place, amount_usd, title}] (placement prizes only, USD). The house fills the rest; a key it fills, or any upload, is refused

Output Schema

Name	Required	Description	Default
`id`	Yes
`stage`	Yes
`terms`	Yes
`checks`	Yes
`status`	Yes
`wallet`	Yes
`cluster`	Yes
`deposit`	Yes
`scoring`	Yes
`decision`	Yes
`proposal`	Yes
`rejection`	Yes
`checked_at`	Yes
`next_steps`	Yes
`program_id`	Yes
`competition`	Yes
`rules_sha256`	Yes
`competition_id`	Yes
`review_deadline`	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 declare the write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds substantial context beyond that: the draft is internal and unlisted, house-filled keys or uploads are refused, non-template briefs need funding first, and it enumerates the error contract (401 no key, 404 another account's proposal, 403 no linked wallet).

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?

Purpose is front-loaded, but the body is a chain of semicolon-joined run-ons and parenthetical asides that cram authentication mechanics, error codes, and scoring alternatives into single sentences. Much of the auth/sign-in narrative (makefun login, POST /api/agents/connect, /skill.md step 1) is procedural backstory an agent invokes far less often than the tool itself.

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?

With an output schema present the return values need no explanation, and the description still covers the 201 payload shape, auth prerequisites, permission failures, and the follow-on workflow (checks, update, deposit). For a mutation tool with a nested object parameter, nothing needed to call it correctly is absent.

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 nested proposal object is already documented in detail inside the schema (duration_hours, harness, scoring, prizes). The description largely restates those rules — "never a date", "placement prizes only, USD", wallet funding — rather than resolving ambiguities the schema leaves open, so it sits at the baseline.

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?

The opening clause names a specific verb and resource ("Start a proposal of a competition you sponsor") and immediately distinguishes the artifact created: a draft never listed until approved, minting a 16-byte competition id. An agent can tell this apart from proposal_update (edits) and proposal_checks (validates) without opening any 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 routes to siblings explicitly ("proposal_checks runs them, proposal_update edits it") and later to proposal_deposit once checks pass, plus states the custom-scoring path requires a deposit first. What's missing is an explicit "don't use this if..." boundary — e.g. how it differs from proposal_request_setup — but the when-to-use context is otherwise clear.

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.