Skip to main content
Glama
Sign In
Gamealia

Gamealia

Official
by gamealia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Update the game listing

gamealia_update_listing
DestructiveIdempotent

Edits an existing game listing so only supplied fields change, including localized text, cover or thumbnail uploads, tags, and permissions; permission updates apply with the next approved version.

Instructions

Edits an existing game's listing (needs login): only the fields given change and they replace the current values; coverPath/thumbPath upload a new cover or thumbnail. texts writes developer-authored title/description/controls for one or many locales in one call (validated against the limits; they always win over machine translation): translate the listing yourself (gamealia-translate-listing skill) and save every locale at once. A permissions change only takes effect with the next approved version. Returns the updated game and the permission changes.

Input Schema

NameRequiredDescriptionDefault
gameYesGame slug or id, from gamealia_list_games (a game of the active account)
slugNoNew URL slug and game host (<slug>.gamealia.app), same rules as in gamealia_create_game; fixed once live
tagsNoTags, three kinds in one array: 1-6 categories (genres: what kind of game), up to 8 mechanics (how it plays: match-3, merge, physics, tower-defense…) and attributes (multiplayer, mobile…). Players browse and search by all three.
textsNoDeveloper-written listing text for one or many locales in one call, e.g. {fr:{title, description, controls}, de:{...}}. Limits (trimmed): title 2-60, description 20-2000 or "", controls <= 500 or "". Only the fields given change; {} approves that locale's machine translation as is; null removes the locale. These texts always win over machine translation. Read the current texts and their status with gamealia_get_status {texts:true}.
titleNo2-60 characters. Prefer {es, en}; a plain string is used for both languages
controlsNo0-500 characters. Prefer {es, en}; a plain string is used for both languages
coverPathNoCover image file (PNG/JPEG/WebP, >= 1200x630, ~1.91:1, <= 2 MB)
isolationNocoop-coep only for builds that need SharedArrayBuffer (threads)
thumbPathNoThumbnail file (square, >= 512x512, <= 2 MB)
adsEnabledNoShow Gamealia ads in this game (revenue share)
descriptionNo20-2000 characters. Prefer {es, en}; a plain string is used for both languages
multiplayerNoPlayers per room, or null for single player
orientationNoScreen orientation the game needs; landscape or portrait shows mobile players a rotate-device hint (default any)
permissionsNoBrowser permissions the game needs (microphone/camera), each with a justification; [] removes them. Replaces the current list and its justification (stored in the listing; the reviewer sees it). gamealia_analyze_project suggests them when the build calls getUserMedia. A change takes effect only when a version tested with it is approved (manual review): upload and submit a new version afterwards.
backendHostsNoYour own servers the game talks to, e.g. mp.example.com or *.example.com

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.18
    • changedInput schema / properties / game / description
      Previous value: -"Game slug or id"New value: +"Game slug or id, from gamealia_list_games (a game of the active account)"
    • addedInput schema / properties / orientation / description
      Added value: +"Screen orientation the game needs; landscape or portrait shows mobile players a rotate-device hint (default any)"
    • addedInput schema / properties / slug / description
      Added value: +"New URL slug and game host (<slug>.gamealia.app), same rules as in gamealia_create_game; fixed once live"
  2. First observedv0.1.17

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds real substance: partial-update semantics (only given fields change), replacement semantics for permissions ('Replaces the current list'), the deferred effect of permission changes pending manual review, and the return payload (updated game plus permission changes). It does not flag irreversibility risks directly (e.g. slug being fixed once live is only in the schema) or failure modes, so it stops short of full disclosure.

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 replace-only-given-fields rule are front-loaded, then media, translation and permission caveats follow in a logical order. It is a dense, multi-clause paragraph that partially restates schema limits and the translate skill, but nearly every sentence carries operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter mutation tool with nested objects and no output schema, the description covers the essentials: auth requirement, partial-update behavior, media upload intent, multi-locale text handling, permission deferral, and the return values. The missing piece is guidance on precedence between texts and the top-level localized text fields, which an agent needs to avoid conflicting writes.

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 description coverage is 100%, so the baseline is 3; the description earns above that by explaining the intent behind coverPath/thumbPath (upload replacements) and the semantics of texts (multi-locale write, {} approves machine translation, null removes a locale, always wins over MT). The notable gap is that it never resolves the relationship between the top-level title/description/controls parameters and the texts object, which is the main ambiguity among 15 parameters.

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 ('Edits an existing game's listing') and immediately scopes it: only supplied fields change, they replace current values, and coverPath/thumbPath upload new media. That cleanly separates it from siblings like gamealia_create_game and gamealia_upload_version without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the login prerequisite, routes the agent to gamealia_get_status {texts:true} to read current texts and their status, and points to the translate-listing workflow before saving locales. It also warns that a permissions change only lands with the next approved version, implying the follow-up upload/submit calls. It does not explicitly say when to use this instead of create_game for a new listing, leaving that inference to the reader.

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

Deploy Server

Other Tools