Skip to main content
Glama

Read the Playgama game requirements

get_game_checklist
Read-onlyIdempotent

Every numbered rule a game and its build archive must meet to go up on Playgama, read live from the Game Requirements section of the Playgama wiki. Read it together with the Required steps of the Bridge SDK (get_bridge_sdk_docs, page: api) when you start work on a game, before writing code (layout, sound, saving and ads are decided in the first build), and again before every start_archive_upload: check the game and the archive against each item by its number, fix what fails before uploading, and tell the developer which numbers you could not check yourself. If the requirements cannot be read, say so: never report the archive as checked. Without page: { title, url, markdown, pages, requirements, unavailable } — the index; every requirement page as { page, title, required, description? }, all required; the markdown of every page but the platform-specific requirements as { page, title, url, markdown }; and { page, title } of the pages that could not be read right now — tell the developer their rules were not checked. The platform-specific requirements apply to the partner platforms the game is distributed to: read them by page. With page (an id from pages): that page’s title, url and markdown. A Bridge SDK link inside goes to get_bridge_sdk_docs and a guide link to get_game_guides, as their page, as written.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_game_checklist"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoId of a requirement page from `pages` in the answer without `page`. A link copied from the wiki works as-is (with or without `.md`, with or without an anchor — the anchor is ignored). Omit to get the index with every requirement page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / page / description
      Previous value: -"Id of a nested page from `pages` in the answer without `page`. A link copied from the wiki works as-is (with or without `.md`, with or without an anchor — the anchor is ignored). Omit to get the checklist itself."New value: +"Id of a requirement page from `pages` in the answer without `page`. A link copied from the wiki works as-is (with or without `.md`, with or without an anchor — the anchor is ignored). Omit to get the index with every requirement page."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safe-read profile, but the description adds substantial behavior: the content is read live from the wiki, unreadable pages come back in an `unavailable` list, and the agent must never claim the archive was checked if requirements could not be read. It also discloses the full response shape for both call modes.

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-loads the purpose and timing before the response-shape details, and most sentences carry necessary obligations. It is dense and long, with the output-shape passage reading like a schema dump, but nothing is gratuitous given the absence of an output schema.

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?

No output schema exists, so the description must document return values — and it does, covering the index mode, the per-page mode, the `unavailable` list, and the mandatory caveat to the developer. For a single optional-parameter read tool, nothing an agent needs 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 `page` is already documented, including the .md/anchor tolerance. The description goes further by explaining which pages must be read individually (platform-specific requirements for partner platforms) and that wiki links map to other tools' `page` ids, adding real meaning beyond the schema.

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: reading every numbered rule a game and its build archive must meet on Playgama, live from the Game Requirements wiki section. It distinguishes itself from siblings by name, routing Bridge SDK links to get_bridge_sdk_docs and guide links to get_game_guides.

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 timing: at the start of work on a game, before writing code, and again before every start_archive_upload, plus the pairing with get_bridge_sdk_docs (`page: api`). It also states the follow-through obligation (check each item by number, fix failures, tell the developer which numbers could not be checked).

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