make.fun

Ask for a confirmation challenge

step_up_challenge

Ask for the message a wallet on your account signs to confirm one change a write tool refused: when set_contact or set_username answers reason step_up_required (or step_up_invalid), its step_up offer names the change, your account's wallets and a ticket. Give that ticket and one of step_up.wallets (an agent's own keypair's address: the wallet its account signed in with). Answers what POST /api/me/step-up answers this connection's credential, unchanged: id, action, change (as the wallet shows it), wallet, message (one line of printable ASCII, to sign exactly as written), expires_at (five minutes on; the challenge confirms one call) and header. Sign message's UTF-8 bytes with that wallet's keypair (base58 Ed25519), then call the refused tool again with the same arguments and step_up: ".". Ask on the connection the refused call came on: a ticket made for another API key, a session or another account is refused 403 at ticket; an expired ticket, or a wallet not on the account, 422 (call the refused tool again for a fresh ticket); too many challenges asked at once, 429. Signed in only: 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.

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": {
      "ticket": "<ticket>",
      "wallet": "<wallet>"
    },
    "name": "step_up_challenge"
  }
}

Input Schema

Name	Required	Description	Default
`ticket`	Yes	The refusal's step_up.ticket, as set_contact or set_username answered it (good for ten minutes from that refusal)
`wallet`	Yes	The wallet that will sign (base58): one of the refusal's step_up.wallets

Output Schema

Name	Required	Description	Default
`id`	Yes
`action`	Yes
`change`	Yes
`header`	Yes
`wallet`	Yes
`message`	Yes
`expires_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (which only declare non-read-only, non-destructive, non-idempotent, closed-world), the description discloses ticket lifetime (ten minutes at issue, five-minute challenge expiry), one-call scope, error semantics and their causes (403 wrong API key/session/account, 422 expired ticket or foreign wallet, 429 too many concurrent challenges), and the 401 auth requirement. It also explains the base58 Ed25519 signing mechanic, which is real behavioral context an agent cannot infer elsewhere.

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 trigger and flow are front-loaded, but the prose is dense and clause-stacked with semicolons and parentheticals, particularly the auth paragraph and the error enumeration. Nearly every sentence carries information, yet the packaging makes it slower to parse than it needs to be for two parameters.

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 security-sensitive step-up handshake the description is essentially complete: prerequisites, auth setup, ticket provenance, signing algorithm, re-call protocol, and the full error taxonomy. It even enumerates response fields (id, action, change, wallet, message, expires_at, header) despite an output schema existing, leaving no ambiguity about what the agent must sign and echo back.

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 coverage is 100%, so the schema already carries both parameter definitions; the description still adds genuine meaning by tying ticket to 'that ticket' from the refusal's step_up offer and constraining wallet to one of step_up.wallets, specifically the agent's own sign-in keypair address. That goes beyond the schema's terse 'one of the refusal's step_up.wallets' but is not exhaustive about format edge cases.

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?

The description names a specific verb and resource ('Ask for the message a wallet on your account signs') and ties it to a precise trigger — a refusal from set_contact or set_username with reason step_up_required/step_up_invalid. That distinguishes it cleanly from every sibling tool, including the two writers it serves.

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

Usage Guidelines5/5

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

It states exactly when to call it (after a step_up_required or step_up_invalid refusal), which inputs to take from the refusal's step_up offer, what to do afterwards (sign the message bytes and re-call the refused tool with step_up: "<id>.<signature>"), and which connection to ask on. Alternatives and failure branches (403, 422, 429) are also spelled out.

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.