Twinr

Update app icon

update_app_icon

DestructiveIdempotent

Replace the app's icon with an image from a public https link (image_url) or from create_image_upload (upload_id). Icon: PNG or JPEG, square (1024x1024 recommended), at most 5 MB, transparency allowed. Launch screen: PNG, JPEG or GIF, exactly 1062x2100 pixels, at most 5 MB. Twinr does not resize or crop images. The change reaches users only after a new build. After it succeeds, offer to start a new build and wait for the merchant's yes. Never call start_build unprompted. If this project's Twinr section (replit.md on Replit, otherwise AGENTS.md) has no application_id, call list_apps, show the merchant every organization and its apps, and ask which app this project is. Never choose one yourself, and never infer it from the project's name or URL. Then record it in the project's Twinr section. Before calling this tool, tell the merchant which app you are changing by name, e.g. "Updating the icon for Shop Name…".

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": {
      "app_id": "<app_id>"
    },
    "name": "update_app_icon"
  }
}

Input Schema

Name	Required	Description
`app_id`	Yes	The application_id recorded in this project's Twinr section.
`image_url`	No	A public https link to the image. Send this or upload_id.
`upload_id`	No	The upload_id from create_image_upload. Send this or image_url.

Output Schema

Name	Required	Description	Default
`message`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds substantive context beyond that: Twinr does not resize or crop, the change reaches users only after a new build, and a merchant confirmation step is required before starting the build. It also mandates announcing which app is being changed, which is real operational behavior an agent cannot infer from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action and input choice are front-loaded, and most sentences carry required constraints or guardrails. However, the full launch-screen image spec is tangential to this tool and adds length, and 'wait for the merchant's yes' plus 'Never call start_build unprompted' partially restate each other.

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 destructive mutation with three parameters and an output schema, the definition covers prerequisites, valid inputs, post-success actions, and confirmation protocol. Nothing an agent needs to call this correctly 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 100%, so the baseline is 3, but the description adds genuine meaning: the image must be a public https link, and the accepted formats and constraints (PNG/JPEG, square, 1024x1024 recommended, max 5 MB, transparency allowed) tell the agent what values are valid for image_url. It does not add anything for app_id beyond the schema's own description.

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: 'Replace the app's icon with an image from a public https link (image_url) or from create_image_upload (upload_id)'. It also distinguishes itself from the sibling update_launch_screen by spelling out the separate launch-screen image spec, so an agent can tell the two apart immediately.

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?

Explicitly routes between the two input paths (image_url vs upload_id), states the prerequisite that app_id must come from the project's Twinr section, names the fallback (call list_apps and ask the merchant) when absent, and forbids specific behaviors ('Never choose one yourself', 'Never call start_build unprompted'). Both when-to-use and when-not-to-use are covered with named alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Twinr 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.

Resources

Need Help?