Twinr

Update launch screen

update_launch_screen

DestructiveIdempotent

Replace the app's launch screen 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_launch_screen"
  }
}

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

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the mutation profile is known; the description adds genuinely useful behavior — no resizing or cropping, and changes only reaching users after a new build. However, it does not say whether the previous launch screen is recoverable or how the remote image URL is fetched server-side, which matters given the declared destructive hint.

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 and source options are front-loaded, which is good, but the block is dense and mixes asset specs, an irrelevant icon paragraph, and multi-step onboarding rules in one wall of prose. The icon sizing paragraph does not belong in a launch-screen definition and dilutes focus.

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?

With an output schema present, return values need not be explained, and the description covers the remaining gaps: prerequisite app_id resolution, asset constraints, merchant communication, and next-step build behavior. Nothing an agent needs to invoke this correctly appears to be 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% and both optional params already document the either/or relationship, so the schema does most of the work. The description still adds real meaning by stating accepted formats, exact 1062x2100 dimensions, and the 5 MB cap that the schema cannot express.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 launch screen") and names both accepted image sources, routing agents to the sibling create_image_upload. The embedded "Icon:" specification paragraph is confusing for a launch-screen tool and slightly blurs the distinction from update_app_icon.

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 states the pre-call workflow: resolve application_id via list_apps when absent, present every organization and app, never infer from project name or URL, and announce the app by name before calling. It also gives a clear post-call condition (offer a new build, wait for consent) and an explicit prohibition ("Never call start_build unprompted").

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?