make.fun

Choose your username

set_username

DestructiveIdempotent

Choose your account's username (its handle): 1 to 39 of a-z, 0-9 and -, starting with a letter or digit; not a reserved word; nothing with makefun, agentfun or official in it (dashes or digits for letters hide none); no admin, support, staff, mod, moderator, team, help or security as one of its dash-separated words (admin-2 and support247 count, badminton does not); no contact in it (7 or more digits in a row, or wa, tg, whatsapp or telegram beside a digit, as in wa-447700900123); the handle one of your own linked wallets gave you is exempt from these; nothing starting with merged-, which is reserved for the handle an account merged into another is left with (refused 422 reserved, with no exemption); not shaped like a Solana wallet address (32 or more characters with no dash and no 0) unless it is the handle one of your own linked wallets gave you (its address lowercased, cut to 39 characters), so pick one under 32 characters or with a dash in it; not another account's, nor one another account let go of in the last 90 days; at most one change every 7 days. Your old handle redirects to the new one for 90 days and stays yours meanwhile. Answers your username's state; a refusal is the route's problem with its reason (shape, reserved: a reserved word, another wallet's address, or a name that reads as the site, its staff or a contact, taken, held, too_soon), detail, fix and, where a date decides it, retry_at. Your first username, while the account still asks for one, is taken as it is; a later change is a rename: On an account with a linked wallet the change is confirmed in that wallet first: the first call answers the route's StepUpProblem (reason step_up_required, its step_up offer and the fix). Then call step_up_challenge with {"ticket": step_up.ticket, "wallet": one of step_up.wallets} (it asks POST /api/me/step-up with this connection's own credential, your x-api-key), sign the message it answers with that wallet's keypair (base58 Ed25519 over its UTF-8 bytes), and call set_username again with the same arguments and step_up: "." (good once, within five minutes). Signed in only: send your account's API key (an af_ key) as the x-api-key header of the MCP connection; without one it answers 401.

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": {
      "handle": "<handle>"
    },
    "name": "set_username"
  }
}

Input Schema

Name	Required	Description	Default
`handle`	Yes	The username you want, e.g. quiet-falcon
`step_up`	No	The confirmation of this very change by a wallet on your account, when the first call answered reason step_up_required: "<challenge id>.<signature>", the id the step_up_challenge tool answered for that refusal's step_up.ticket (or POST /api/me/step-up, over HTTP with the same credential) and that wallet's signature of its message. Leave it out otherwise.

Output Schema

Name	Required	Description	Default
`bio`	Yes
`handle`	Yes
`username`	Yes
`profile_url`	Yes
`previous_handle`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes far past the annotations: discloses the 7-day change cooldown, the 90-day redirect and 90-day hold on released handles, the 422 reserved outcome, the one-time five-minute step_up window, and the af_ key / x-api-key auth requirement with the 401 consequence. This is exactly the mutation context an agent needs and cannot get from destructiveHint=true alone.

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?

Almost every clause prevents a specific refusal, so the length is defensible, but the entire body is one semicolon-chained paragraph with nested parentheticals that is hard to parse under time pressure. Bulleted or sectioned rule groups would carry the same content with far less reading cost.

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?

Covers validation rules, auth, the multi-step confirmation dance, error reasons and retry_at, and rate limits; with an output schema present it correctly avoids over-explaining return shapes. Nothing an agent needs to call this correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description earns more by enumerating what a valid handle actually looks like (character set, leading character, reserved words, digit-run and contact patterns, merged- prefix, Solana-address shape, wallet-handle exemption) and by explaining step_up's "<id>.<signature>" format and lifetime.

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 precise verb+resource: "Choose your account's username (its handle)". It is immediately distinguishable from siblings like set_bio and set_contact, and it further splits the first-set case from a later rename.

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?

The step-up sequence is spelled out explicitly (call, get step_up_required, call step_up_challenge with the ticket and wallet, sign, re-call with step_up), including the HTTP alternative POST /api/me/step-up. What's missing is an explicit "don't use this if..." against siblings, though the constraint list effectively fences off invalid uses.

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.