Skip to main content
Glama

Update the game live in the Playgama catalog

send_playgama_catalog_update
Destructive

Send this archive and the saved form to the Playgama catalog as an update of the game live there, without moderation: once it is published, every catalog player gets it and no moderator checks it first. Write updateNote — what players will notice in this update — every time; a refused note writes nothing: fix it and call again. Call it only on the developer’s explicit yes in this conversation: first tell them the game, the archive and that the game live in the Playgama catalog will be updated for all its players with no moderation; a yes to an earlier update or to a sandbox publish does not count. Before asking, read get_submission_state with this archiveId and reviewType AUTO: it says whether this call would be refused, in the same words. Only a game live in the catalog takes it (autoReviewPlatforms holds PLAYGAMA); a first publication and every other platform go to moderation, which a human submits in the console. Answers outcome PENDING and releaseId: follow that PLAYGAMA publication in get_publications, read before the call too. On FAILED players keep the previous build. Until it ends, another publication of the game, to the catalog or the sandbox, is refused with 409 PUBLICATION_IN_PROGRESS. Never call again on an old yes: the form goes as it is when the call goes in, so another call is a new update, after get_submission_state and a new yes. Refusals (reason): AUTO_REVIEW_UNAVAILABLE — not live in the catalog; NO_CHANGES — the archive and the form are those of the last submit; PUBLICATION_IN_PROGRESS; and every reason get_submission_state names.

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>",
      "archiveId": "<archiveId>",
      "updateNote": "<updateNote>"
    },
    "name": "send_playgama_catalog_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
archiveIdYesThe archive to send: one of this game whose build check PASSED (get_archive_status `state`), the one get_submission_state judged with `reviewType` AUTO. Its form goes with it, as saved
updateNoteYesWhat a returning player will notice in this build, 80 to 500 characters, 1 to 4 sentences. Not a changelog: pick the one or two changes a player would actually feel (a new level, controls that work differently, a boss that got easier) and say them the way you’d tell a friend who played last week. Skip refactors, build settings and fixes nobody could see. If it fixes something players complained about, say so. Required: this update replaces the build every catalog player has now. It is kept with this release. Write it in the voice `story` of update_application_form describes. Non-Latin letters and links are refused. Here the note cannot be left out: fix a refused one and send it again.
applicationIdYesGame id from list_applications

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / applicationId / description
      Previous value: -"Application (game) id, as returned by list_applications"New value: +"Game id from list_applications"
    • changedInput schema / properties / updateNote / description
      Previous value: -"What a returning player will notice in this build, 80 to 500 characters, 1 to 4 sentences. Not a changelog: pick the one or two changes a player would actually feel (a new level, controls that work differently, a boss that got easier) and say them the way you’d tell a friend who played last week. Skip refactors, build settings and fixes nobody could see. If it fixes something players complained about, say so. Required: this update replaces the build every catalog player has now. It is kept with this release. Always write it in English, even when you talk to the developer in another language: translate, don’t switch. Write as the developer posting in the game’s chat, not as an announcement: first person, short sentences, contractions, plain words, one or two short paragraphs. Plain text only: no headings, lists, markdown, links, e-mail addresses or hashtags, and one emoji at most. Avoid ad words and AI tells: immersive, dive into, embark, journey, unleash, elevate, seamless, thrilling, \"whether you’re…\", \"not just X but Y\", lists of three, em dashes. Don’t open with the game’s title, \"Welcome to\" or \"Hey everyone\". Use only what you know from the game and from building it; never invent a backstory, feelings or numbers. Non-Latin letters and links are refused: fix the text or leave it out, and never let it block the rest of the call. Here the note cannot be left out: fix a refused one and send it again."New value: +"What a returning player will notice in this build, 80 to 500 characters, 1 to 4 sentences. Not a changelog: pick the one or two changes a player would actually feel (a new level, controls that work differently, a boss that got easier) and say them the way you’d tell a friend who played last week. Skip refactors, build settings and fixes nobody could see. If it fixes something players complained about, say so. Required: this update replaces the build every catalog player has now. It is kept with this release. Write it in the voice `story` of update_application_form describes. Non-Latin letters and links are refused. Here the note cannot be left out: fix a refused one and send it again."
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructive=true and non-idempotent, and the description justifies those flags with real consequences: no moderator gate, every catalog player receives the build, a FAILED release leaves players on the previous build, and repeat calls are new updates because the form is frozen at call time. It also enumerates refusal reasons and the 409 PUBLICATION_IN_PROGRESS lockout on other publications.

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?

Front-loaded with the destructive, no-moderation fact and the consent requirement, and nearly every sentence carries a distinct constraint. It is long and heavily emphasized with bold and parentheticals, with some overlap against the already-rich schema text, but the density is defensible for an irreversible publish action.

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?

There is no output schema, so the description carries return semantics itself and does: outcome PENDING plus releaseId, follow-up via get_publications, and post-failure state. Combined with prerequisites, refusal reason enumeration, and concurrency behavior, nothing an agent needs before invoking this destructive call is missing.

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 coverage is 100% and the field descriptions already explain archiveId's PASSED-build/AUTO-review requirement and updateNote's length, tone, and no-links rule in depth. The description reinforces that updateNote is mandatory and that a refused note writes nothing, but adds little terminology or constraint beyond what the schema already states.

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?

States a specific verb and resource ('Send this archive and the saved form to the Playgama catalog as an update of the game live there, without moderation') and immediately scopes it to live catalog games only, distinguishing it from moderation-bound first publications and other platforms. An agent can tell this apart from publish_sandbox or a console submission 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?

Gives explicit when-to-use conditions ('only on the developer's explicit yes in this conversation'), disqualifies invalid yeses (an earlier update's yes, a sandbox publish yes), mandates a get_submission_state precheck with the exact reviewType, and names the alternative path for first publications and other platforms. Exclusions and sequencing are fully spelled out.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources