Skip to main content
Glama

Create the game listing

gamealia_create_game

Creates a new draft game listing in your active developer account with slug, localized text, tags, settings, and optional cover/thumbnail, ready for version upload and review after autotest passes.

Instructions

Creates a new game listing in the active developer account (needs login; not idempotent: a taken slug fails): slug, title/description/controls in es and en, tags, orientation, multiplayer, ads on/off, backend hosts, permissions; optionally uploads a cover and thumbnail (make them with gamealia_generate_cover). The game stays a draft, not public, until a version is approved. Call it once per game, after gamealia_run_autotest passes; to change an existing listing use gamealia_update_listing. Returns the game (id, slug, status); next gamealia_upload_version.

Input Schema

NameRequiredDescriptionDefault
slugYesURL slug and game host (<slug>.gamealia.app): a-z, 0-9 and -, 3-40 chars, starting and ending with a letter or digit, not reserved (www, api, cdn, ...); fixed once live
tagsYesTags, 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}.
titleYes2-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)
descriptionYes20-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. Changed1 schema field changedv0.1.18
    • addedInput schema / properties / orientation / description
      Added value: +"Screen orientation the game needs; landscape or portrait shows mobile players a rotate-device hint (default any)"
  2. First observedv0.1.17

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare non-readonly, non-idempotent, non-destructive, open-world, but the description adds concrete substance beyond them: login is required, a taken slug fails (matching non-idempotent), cover/thumbnail uploads are side effects, and the game remains a draft and non-public until a version is approved. It even discloses the return shape (id, slug, status).

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 action and the critical non-idempotent/login caveats, and the sibling references are placed usefully. It is a dense semicolon-chained paragraph, though, so the field list reads as a run-on rather than a scannable structure.

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?

For a 14-parameter, mutation-heavy tool with nested locales and no output schema, the description covers prerequisites, side effects, draft visibility, return values, and follow-up steps. Nothing an agent needs in order to call it correctly is 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%, so the baseline is 3. The description still adds value by summarizing the es/en title/description/controls, tags, orientation, multiplayer, ads, backend hosts, permissions, and the optional cover/thumbnail paths, giving an agent a coherent overview before it opens each parameter.

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 ('Creates a new game listing in the active developer account') and immediately lists the fields it owns. It differentiates itself from gamealia_update_listing, which it names explicitly for the update case.

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?

Explicit sequencing: call once per game, after gamealia_run_autotest passes, and use gamealia_update_listing for existing listings. It also names gamealia_generate_cover for producing the optional images and points to gamealia_upload_version as the next step, leaving little to inference.

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