Twinr

Create image upload

create_image_upload

Prepare the upload of a local image file (the merchant gave a file path) for the app icon or launch screen. Use this ONLY when the merchant gives a local file path; if they give a link, prefer image_url on the update tool and skip this. Returns a curl command for the merchant to run on the computer that has the file. If the command fails, call create_image_upload again for a fresh link; if that fails too, ask for a public https image URL instead. 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. 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>",
      "purpose": "<purpose>",
      "file_path": "<file_path>"
    },
    "name": "create_image_upload"
  }
}

Input Schema

Name	Required	Description
`app_id`	Yes	The application_id recorded in this project's Twinr section.
`purpose`	Yes
`file_path`	Yes	The image's path on the merchant's computer.

Output Schema

Name	Required	Description	Default
`command`	Yes
`upload_id`	Yes
`expires_at`	Yes
`instructions`	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?

Beyond the annotations (readOnly=false, destructive=false, idempotent=false), it discloses the key non-obvious behavior: the tool does not upload the bytes itself but returns a curl command the merchant runs on the machine holding the file. It also discloses retry semantics for expired/failed links, per-purpose format and size limits, and that no resizing or cropping occurs — all things the annotations cannot convey.

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?

It is long but front-loaded and dense — the routing rule comes first, then the failure path, then format constraints, then the app_id procedure. The per-purpose constraint sentences are terse and earn their place, though the app_id and 'announce the app name' instructions could be tightened into fewer words without losing information.

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?

An output schema exists, so the description needn't explain the returned link structure, and the description does note that a curl command comes back. For a moderately complex three-parameter tool with prerequisite resolution logic, it covers preconditions, fallbacks, limits, and side effects with nothing an agent needs 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 67% and the schema already defines app_id and file_path, but the description adds real meaning to the purpose enum by pairing each value with its own constraints (icon: PNG/JPEG, square, 1024x1024, 5 MB, transparency allowed; launch screen: PNG/JPEG/GIF, exactly 1062x2100, 5 MB). That constraint mapping is exactly the value-add beyond the bare enum, though the semantic distinction between the two enum values could be stated more directly.

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 opens with a specific verb+resource: 'Prepare the upload of a local image file ... for the app icon or launch screen.' It explicitly distinguishes itself from the sibling path by saying to prefer image_url on the update tool when the merchant supplies a link, so an agent can route correctly without inspecting other schemas.

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 a hard precondition ('Use this ONLY when the merchant gives a local file path'), names the alternative for the other case, and gives an explicit failure/retry protocol including the fallback to asking for a public https URL. It also spells out the app_id resolution procedure (check Twinr section, else list_apps, never infer from name/URL) and a confirmation step before calling.

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?