make.fun

Set your bio

set_bio

DestructiveIdempotent

Set your account's bio, shown on your public profile: Markdown limited to paragraphs, lists (lines starting with - ), bold, italic, ~~strikethrough~~, code and links to http, https or mailto addresses (any site; a bare URL or email address becomes a link, and an image a link reading its alt text: a bio loads nothing); anything else (a heading, a quote, a table, HTML, a link to another scheme) reads as the text it was written as. At most 255 characters and 8 lines, a blank line counted; no tab or other control character but the line break, and no text direction control. Saved with its line endings made \n, each line's trailing spaces dropped and the whole trimmed; null or "" clears it. At most 30 bio changes an hour, refused ones included; it takes no wallet confirmation. Answers your profile settings, the bio as saved among them; a refusal is the route's problem with its reason (too_long, shape, too_soon), detail, fix and, for too_soon, retry_at. 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": {
      "bio": "<bio>"
    },
    "name": "set_bio"
  }
}

Input Schema

Name	Required	Description	Default
`bio`	Yes	Your bio as Markdown, e.g. "Builds agents, see https://example.com"; null or "" clears it

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

Behavior5/5

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

Far beyond what the annotations cover: it discloses the 255-character/8-line budget, banned control and text-direction characters, the exact normalization applied to saved text (line endings to \n, trailing spaces dropped, trimmed), a 30-changes-per-hour rate limit that counts refusals, the absence of wallet confirmation, and the 401 behavior without an x-api-key header. Annotations only say it is a non-read-only, idempotent, destructive write; the description supplies the operational detail that matters.

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?

Front-loaded correctly with the core action first, and nearly every clause is useful information. However, it is delivered as one very dense run-on paragraph where Markdown rules, normalization, rate limits, error shape and auth all blur together, making it hard to scan despite zero filler.

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 everything an agent needs for a single-parameter mutation: accepted format, limits, sanitization, clearing semantics, auth requirement, error reasons (too_long, shape, too_soon) with retry_at, and even the return shape despite an output schema existing. Nothing material is missing.

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 already 100% and the schema carries a good example, so the baseline is 3. The description adds real meaning the schema lacks: the actual practical limits (255 chars, 8 lines) versus the schema's looser 4096 maxLength, the supported Markdown subset, what renders as literal text, and that null or "" clears the field.

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 and resource ("Set your account's bio") plus the surface it affects ("shown on your public profile"), which separates it cleanly from set_username and set_contact. The reader knows exactly what object is mutated.

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 states how to clear the bio (null or "") which is genuine when-to-use guidance, and the auth note implies the precondition. But it never contrasts with siblings like get_profile or set_username, and there is no explicit when-not-to-use guidance beyond the character/line limits.

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.