make.fun

Get a proposal's status

proposal_status

Read-onlyIdempotent

Your proposal's status: its stage (draft, checking, fix_needed, setup_requested, in_review, listed, returned, withdrawn, expired or held), its scoring (custom while it is a brief for the make.fun team to set up, set_by house once the team attached the harness; setup: the brief and the team's note), its checks, rules_sha256 (the composed competition's hash the escrow commits: recompute it from the competition to check it), review_deadline (the last second the house may approve it; after it anyone may return the deposit), the deposit as cleared and then as the chain holds it (the Proposal account, its vault, the pot in base units, submit_tx, an explorer link), the decision's transactions, the rejection document when it was returned (an RFC 9457 problem naming every reason with its fix; its sha256 is the reason_sha256 close_proposal recorded on chain) and next_steps. 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_status"
  }
}

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.5/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavior: the auth flow required (login/connect, or a keypair-minted af_ key sent as x-api-key) and the exact failure modes (401 unauthenticated, 404 for someone else's proposal). It also explains the semantics of stage values and deposit states rather than just listing field names. It stops short of return-format or pagination/performance context, but the added auth and error disclosure is substantial.

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 tool is a one-parameter read with a full output schema, yet the description is a single sprawling sentence dense with nested parentheticals, making it hard to scan. Much of the space restates returned fields that the output schema already defines, and the auth instructions are buried mid-sentence rather than front-loaded as a prerequisite. Content is relevant but the structure costs readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a read-only tool with complete annotations, 100% schema coverage, and an output schema, the description supplies what structured fields cannot: stage and deposit-state semantics, the meaning of rules_sha256 and reason_sha256 linkage, and the full auth requirement. An agent could call it correctly from this. The only gap is routing guidance relative to sibling status/check tools.

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 description coverage is 100% and the single parameter is already well documented, including where the id comes from (proposal_create's id, GET /api/sponsor/proposals). The description adds no syntax, format, or edge-case detail about proposal_id beyond the schema, so the baseline of 3 applies.

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 description states a specific verb+resource ('Your proposal's status') and enumerates the facets returned: stage, scoring, checks, rules_sha256, review_deadline, deposit, decision transactions, rejection document, next_steps. An agent knows exactly what it gets. It never contrasts itself with nearby siblings such as proposal_checks or get_entry_status, which also surface status-like data, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives real usage constraints — signed-in only, restricted to your own proposals, 401 without a key and 404 for another account's proposal — which tells the agent the preconditions for calling it. What it never says is when to prefer it over proposal_checks, get_entry_status, or proposal_deposit, so alternative selection is left to inference.

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.