make.fun

Run a proposal's checks

proposal_checks

Idempotent

Run every automatic check of your proposal and store the verdicts: its schema, the competition it composes, its prizes (placement only, within this server's floor and ceiling and the escrow's cap), its schedule (competition.duration_hours at least the shortest entries window; make.fun sets the opening, the review hours from now at the soonest, the deadline and the final window from it), its category, no uploaded files, its rules reviewed since the make.fun team finished a custom setup, on a code bounty the test pack its harness names (held to the record the team built for this proposal: nothing of yours to change, the team fixes a failing one), the wallet (read on chain: it holds the pot and the SOL the deposit takes) and your account's proposal limits. Answers {proposal, problem}: the proposal (status ready when every check passed, else needs_fix; a custom brief's draft once every one but the template's passed, which proposal_deposit then funds) and the RFC 9457 problem a deposit would be refused with (null when every check passed), every check with its reason and each failed one with its fix. 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_checks"
  }
}

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
`problem`	Yes
`proposal`	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?

Goes well past the annotations: it discloses the side effect of storing verdicts (consistent with readOnlyHint=false and idempotentHint=true), the on-chain wallet read, the server floor/ceiling and escrow cap applied to prizes, the make.fun-derived schedule rules, and that a failing team-built test pack is fixed by the team rather than the caller. Auth behavior is fully spelled out with concrete failure modes (401 without an af_ 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 purpose is front-loaded and almost no sentence is pure filler, but the body is a single wall of nested parentheticals (schedule rules, prize caps, auth flow) that is hard to scan and forces re-reading. It also restates return values already covered by the output schema, which is redundant bulk.

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 tool that gates a deposit, this covers everything an agent needs: what is checked, what verdict states mean (ready vs needs_fix vs custom-brief draft), the downstream action, auth prerequisites, and error conditions. Nothing required for a correct call is missing, even ignoring the output schema.

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 the schema already documents it at 100% coverage including its provenance ('proposal_create answers it as id; GET /api/sponsor/proposals lists yours'). The description adds no further meaning about the id beyond what the schema states, so the baseline of 3 for high schema coverage applies.

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?

Opens with a specific verb+resource+effect: 'Run every automatic check of your proposal and store the verdicts,' then enumerates the actual check domains (schema, competition composition, prizes, schedule, category, files, rules, harness test pack, wallet, account limits). This is unmistakably distinct from siblings like proposal_status, proposal_deposit, or proposal_update.

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?

Gives strong preconditions and exclusions: signed-in only, own proposals only, with the exact remediation path (makefun login / POST /api/agents/connect, or POST /api/auth/solana/key), plus the gating condition that a 'ready' verdict is what proposal_deposit then funds. It stops short of explicitly contrasting with proposal_status or saying when not to run checks (e.g., cost/time of re-running), so it is clear context rather than full when/when-not guidance.

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.