Playgama MCP - Publish & Manage HTML5 Games

Read the Playgama game guides

get_game_guides

Read-onlyIdempotent

Recommendations for building, monetizing and optimizing a game for Playgama, read live from the Playgama wiki: loading and the first session, responsive layout, controls, sound, saving progress, ad and purchase design, performance. Moderation checks none of it — the rules are get_game_checklist — so a guide is never a reason to block an upload. Read the guide that matches the work at hand: layout, sound or controls while building the game, monetization while placing ads and purchases, performance while optimizing. Without page: { title, url, markdown, pages } — the index and one { page, title, required, description? } per guide. With page (an id from pages): that guide’s title, url and markdown. A Bridge SDK link inside goes to get_bridge_sdk_docs and a requirements link to get_game_checklist, 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_guides"
  }
}

Input Schema

Name	Required	Description	Default
`page`	No	Id of a guide from `pages` in the answer without `page`, e.g. "game-development/responsive-layout". 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 of guides.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds genuine value beyond that by disclosing the return shape in both modes and the moderation non-blocking rule, but with annotations carrying the risk profile this lands at a solid 3 rather than higher.

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 resource and the crucial 'never a reason to block' caveat before the retrieval mechanics. Dense but every clause carries routing or return-shape information; it is slightly long and the middle guidance sentence repeats the topic list from the opening.

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?

With a single optional parameter and no output schema, the description fully compensates by spelling out both response shapes, the pages index format, and where cross-links lead. Nothing needed to call it correctly or interpret the result 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% and the schema itself explains the page id and link-copy tolerance, so the baseline is 3. The description adds the behavioral consequence of omitting page (index plus pages array) versus supplying it (single guide markdown), which the schema does not state.

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 (read live from the Playgama wiki) and resource (game guides covering building, monetizing, optimizing), and enumerates the covered topics. It also explicitly distinguishes itself from get_game_checklist and get_bridge_sdk_docs by name, so an agent can route without opening schemas.

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 mapping ('layout, sound or controls while building... monetization while placing ads... performance while optimizing') and a clear exclusion: moderation never blocks on guides, the rules are get_game_checklist. Both the alternative and the negative condition are stated.

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

All Playgama MCP - Publish & Manage HTML5 Games tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?