Skip to main content
Glama
Sign In
Gamealia

Gamealia

Official
by gamealia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Submit for review

gamealia_submit_for_review

Submits a tested game version for manual Gamealia review with release notes after user confirmation, so a build can move toward approval.

Instructions

Submits a game's newest version that passed the server autotest (state tested) for manual review by Gamealia, with release notes. Call it only after the user has confirmed they want to submit this version, and after gamealia_upload_version (skip it if that ran with submit:true). Needs login; fails if no version is tested, or if newly requested permissions lack a justification. Returns the version, normally awaiting_review; if permissions changed since its autotest the server re-tests it first. Then check gamealia_get_status later.

Input Schema

NameRequiredDescriptionDefault
gameYesGame slug or id, from gamealia_list_games (a game of the active account)
notesNoRelease notes for the reviewer, up to 2000 characters (default empty)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 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 / notes / description
      Added value: +"Release notes for the reviewer, up to 2000 characters (default empty)"
  2. First observedv0.1.17

TDQS

A4.6/5.0
Behavior5/5

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

It discloses critical behavioral traits beyond the annotations, including failure conditions (no version tested, missing permission justification), operational prerequisites (needs login), and dynamic server responses (re-testing if permissions changed).

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 description is highly efficient, packing complex operational logic, prerequisites, and failure modes into a dense but logical paragraph. The structure follows a necessary workflow progression.

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?

Despite lacking an explicit output schema, the description explains what the tool returns (the version, awaiting_review) and outlines the subsequent steps (checking gamealia_get_status). All necessary operational context is present.

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?

While the schema coverage is 100%, the description adds relevant context by specifying that 'notes' are intended for the reviewer, which provides semantic value beyond the raw schema definition.

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 clearly identifies the action (Submits), the resource (game version), and the context (manual review by Gamealia). It differentiates this operation from general version management tools by emphasizing the post-autotest state.

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 provides explicit operational constraints, dictating when to call the tool (after user confirmation) and how it relates to other tools (must run after gamealia_upload_version, unless that tool already ran with submit:true).

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