make.fun

Edit a proposal

proposal_update

DestructiveIdempotent

Edit a draft: proposal is an RFC 7386 JSON merge patch of the proposal as written (a key set to null removes it, an object merges into the one there, anything else replaces it), wallet another linked wallet (name one or both). Its checks reset (status draft): run proposal_checks again. Answers the proposal. Refused (409) once its deposit is on chain, since its rules are frozen at rules_sha256 (withdraw it and propose again), and while a cleared deposit can still land. 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_update"
  }
}

Input Schema

Name	Required	Description
`wallet`	No	The wallet that funds and signs the deposit: one linked to your account (base58); default its first
`proposal`	No	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
`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
`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?

Goes well beyond the annotations (destructive=true, idempotent=true): it specifies that null removes a key, objects merge, anything else replaces, that checks reset to draft status, that writes are refused at 409 once the deposit is on chain even after a cleared deposit can still land, and that a key the house fills or any upload is refused. It also discloses the full auth/error profile (401 without an x-api-key, 404 for another account's proposal).

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 core edit semantics are correctly front-loaded, but the auth paragraph is a compressed run-on covering makefun login, POST /api/agents/connect, POST /api/auth/solana/key, /skill.md step 1, and the x-api-key header — a large amount of connection boilerplate hanging on a 3-parameter tool with full schema coverage. The telegraphic style ("Signed in only, your own proposals: ...") makes it slower to parse than its content requires.

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 mutation tool with nested-object payloads and an output schema present, the description covers mutation semantics, side effects (checks reset), refusal conditions and their remedy, ownership scoping, and the terminal answer ("Answers the proposal"). Nothing an agent needs in order to call it safely is 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 description coverage is 100%, so the baseline is 3, and the description earns an increment by supplying the merge-patch semantics (null removes, object merges, scalar replaces) that the schema does not state. It also clarifies wallet as "name one or both" with the first linked wallet as default, adding meaning beyond the schema's own text.

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 names a specific verb and resource ("Edit a draft") and immediately defines the payload semantics as an RFC 7386 JSON merge patch of the proposal. It implicitly separates this from proposal_create ("withdraw it and propose again") and proposal_checks ("run proposal_checks again"), though those siblings are not called out as explicit alternatives in the first sentence.

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 concrete when-not conditions: refused (409) once the deposit is on chain because rules are frozen at rules_sha256, and the agent should withdraw and propose again instead; it also routes the agent to proposal_checks after an edit since checks reset to draft. That is real exclusion plus alternative-path guidance, though it is buried in prose rather than surfaced up front.

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.