make.fun

Set your contact

set_contact

DestructiveIdempotent

Set or clear your account's own email and phone number, which the site may use to reach you about your entries and prizes. Only your account and the site's admins see them (never on a public page, a leaderboard, the archive, an export or another tool); they are not your sign-in. Give email, phone or both; an absent one is kept, null or "" clears it. A phone number starts with + and the country code (or give phone_country, e.g. US, for a national number) and is stored in E.164. A changed value is unverified until a code sent to it is confirmed. Answers your contact as get_contact does; a bad value is the route's problem (reason invalid_value, error[].path naming the field), refused before any confirmation is asked. 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_contact 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. Verify one over HTTP: POST /api/me/contact/<email|phone>/send sends a 6-digit code to it, POST /api/me/contact/<email|phone>/confirm with {"code"} confirms it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "set_contact"
  }
}

Input Schema

Name	Required	Description
`email`	No	Your email address; null or "" clears it
`phone`	No	Your phone number, e.g. +1 415 555 0123; null or "" clears it
`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.
`phone_country`	No	The country a phone number without + is read in (ISO 3166-1 alpha-2, e.g. US)

Output Schema

Name	Required	Description	Default
`email`	Yes
`phone`	Yes
`verify_channels`	Yes
`email_verified_at`	Yes
`phone_verified_at`	Yes
`email_code_expires_at`	Yes
`phone_code_expires_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Goes well beyond the annotations: privacy scope (never public page, leaderboard, archive, export, or another tool), that values are unverified until a code is confirmed, the single-use five-minute step_up token, the 401 without an af_ key, and the invalid_value error shape with error[].path. Nothing contradicts the destructive/idempotent hints. It loses a point only because the wallet-signing and step-up sequencing, while present, are compressed into a dense parenthesis rather than laid out as steps.

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 every clause carries information an agent needs, but the body is a single run-on block with nested parentheses that forces slow parsing of the step-up sequence. Splitting the auth and verification flow into separate sentences or steps would preserve the content while improving scannability.

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 mutation with a wallet step-up gate, this covers everything an agent needs to succeed end to end: authentication, the refusal and retry path, ticket/signature format and expiry, error reason names, and the out-of-band HTTP verification endpoints. Return values are delegated to the existing output schema, so no gap remains.

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 3 would be the floor, but the description genuinely adds meaning: phone storage in E.164, the phone_country fallback for national numbers, and the full lifecycle of step_up (which ticket, which wallet, base58 Ed25519 over UTF-8 bytes, usable once within five minutes). That is real semantic content the schema's terse descriptions do not carry.

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 pair and resource with explicit scope: "Set or clear your account's own email and phone number." It also names the sibling get_contact as returning the same data, so the agent can separate the read path from the write path without opening a schema.

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?

States when to use it, gives the exact clearing semantics (absent = keep, null/"" = clear), and routes the agent to a concrete alternative for reading (get_contact). It also spells out the conditional branch: only when the first call answers step_up_required does the agent call step_up_challenge and retry.

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.