make.fun

Request make.fun's scoring setup

proposal_request_setup

The earlier way of a custom scoring brief (scoring {custom: {brief, examples}}, written when no house template fits; a code bounty's names its code kind and runtimes, sponsor_templates' code_brief), kept for the proposals that asked it: a custom brief funds first now, so a new one needs no request. proposal_deposit takes it once its checks but the template's pass, its rules unset, and while it is in review the make.fun team sets up how it is scored from the brief (on a code bounty, writes the hidden tests and attaches code-tests); the approval sets its rules on chain, and a rejection returns the whole deposit. This asks the team's setup before any deposit instead: your proposal's checks run (and are stored) and every one but the template's (proposal_bundle, and proposal_category beyond the category being open to sponsored competitions: any open one goes) and the deposit's must pass; then it waits for the team (status setup_requested, stage setup_requested). The team attaches a house template and its knobs as the harness, and, when the template does not fit your category, a category it does fit (the proposal is a draft again, its scoring set by the house: you can no longer change the harness, the rest stays editable; run proposal_checks, then proposal_deposit) or returns it with a note (fix_needed: fix it and request again); either way you get a notification and the note shows on proposal_status. While it waits, proposal_deposit is refused (409). Answers the proposal. Refused with the checks' RFC 9457 problem (400, 422) when one failed, 409 for a proposal on a house template, one waiting already or one past its draft. 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_request_setup"
  }
}

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
`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

A3.7/5.0

Behavior5/5

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

Beyond the annotations, it discloses the full workflow: checks are run and stored, status and stage become setup_requested, the team attaches a house template or returns fix_needed, notifications are sent, and proposal_deposit is refused with 409 while waiting. It also gives error handling for 400, 422, 409, 401, and 404 plus detailed authentication requirements, which is substantial behavioral context.

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?

The definition is a single dense block, front-loaded with legacy context rather than the tool's action, and repeats related concepts across nested clauses. For a one-parameter tool it is substantially overlong and difficult to parse.

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?

Given the complex workflow, it covers the necessary states, side effects, refusals, authentication path, and post-request branching, while the output schema can carry return-shape details. Nothing critical appears missing, even though the information is hard to extract.

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?

With 100% schema coverage for the single proposal_id, the schema already explains that it is a UUID and where to find it. The description adds only that the proposal must belong to the caller, which is useful ownership context but not enough to exceed the baseline for fully documented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description does identify a specific action: requesting the team's scoring setup before a deposit, and it distinguishes this from proposal_deposit. However, the actual purpose is buried in a long historical preamble about legacy custom scoring briefs, so the first sentences do not cleanly state verb and resource.

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 supplies several usage conditions: it is kept for proposals that asked for a custom brief, it asks setup before any deposit, proposal_deposit is refused while waiting, and after a template is attached the agent should run proposal_checks then proposal_deposit. Alternatives such as proposal_deposit, proposal_checks, and sponsor_templates are named, though the guidance is embedded in dense prose rather than organized as clear when/when-not rules.

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.