Playgama MCP - Publish & Manage HTML5 Games

Start a cover upload

start_cover_upload

Destructive

Step 1 of 3 of uploading one cover. Answers uploadUrl and headers: PUT the file there with exactly those headers within an hour, e.g. curl -T cover.png -H "Content-Type: image/png" "<uploadUrl>", then call confirm_cover_upload.

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": {
      "applicationId": "<applicationId>",
      "cover": "<cover>",
      "format": "<format>",
      "contentSize": "<contentSize>"
    },
    "name": "start_cover_upload"
  }
}

Input Schema

Name	Required	Description
`cover`	Yes	Which cover slot of the form this fills. Exact sizes: square = 800×800, portrait = 1080×1920, landscape = 1920×1080. A confirmed cover replaces the one already in its slot.
`format`	Yes	The file’s actual format — it is checked against the bytes on confirm
`contentSize`	Yes	Exact size of the file in bytes (`wc -c < cover.png`). The upload URL is signed for this length and the storage refuses any other. At most 10485760 bytes.
`applicationId`	Yes	Game id from list_applications

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 4, 2026

changedInput schema / properties / applicationId / description

Previous value: -"Application (game) id, as returned by list_applications"New value: +"Game id from list_applications"

First observedSep 11, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=false), the description discloses what the call actually returns (uploadUrl and headers), that the URL is time-bounded to one hour, and that the operation is incomplete until confirm. It does not restate that a confirmed cover replaces an existing one — that lives only in the schema's cover property — and it does not say whether abandoning the flow leaves any state behind.

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

Conciseness5/5

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

Two sentences, zero filler: the sequencing claim is front-loaded, the return values and deadline follow, and the example is compact enough to be actionable rather than explanatory. Every clause carries operational 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?

With no output schema, the description must convey what comes back, and it does (uploadUrl plus headers) along with the TTL and the required next call. For a four-required-param, no-nested-objects initiation step, an agent has everything needed to complete the flow correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including enum explanations for cover and format and a byte-range note for contentSize, so the schema carries the parameter burden and the baseline is 3. The description adds only the indirect signal that headers from the response must match the file's declared format; it explains none of the four parameters itself.

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?

Names a specific action (start a cover upload), places it precisely as step 1 of 3, and by saying 'uploading one cover' it separates itself from the sibling pair start_archive_upload/confirm_archive_upload. An agent can distinguish it from confirm_cover_upload without opening either 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?

The sequence is explicit: do this first, PUT the file to the returned uploadUrl with exactly the returned headers within an hour, then call confirm_cover_upload. It names the follow-up tool and the condition that triggers it, plus a concrete invocation example, leaving nothing to inference.

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

All Playgama MCP - Publish & Manage HTML5 Games 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?