Skip to main content
Glama

klyo games: publish HTML5 browser games

Edit a game's files in a workshop

klyo_game_patch
Destructive

Edits a game's text files (html, htm, js, mjs, css, json, svg, txt, xml, webmanifest) without a ZIP. Target: a game's slug or a waiting-room package's upload_id. The first edit opens a WORKSHOP: a copy of the game next to the version players have, with its own preview address. Players keep playing the previous version until you release the new one (klyo_release_version for a game, klyo_publish_game for a package); the owner sees it in the studio as “New version waiting”. Each item of edits has a path and one of three: old_string with new_string (an exact fragment that must occur once, or add replace_all), content (the whole file or a new file), or delete: true. For a file that exists, pass expected_hash from klyo_game_files: if someone changed the file in the meantime you get a conflict and nothing is saved. The changes of one call are applied all or none. Every changed file goes through the klyo check (malicious code, third-party ads, nothing from outside klyo), and the whole game once more before release. Send an image, sound, font or large file (up to 20 MB) with the ticket from klyo_upload_package and reference it in the edit with from_upload (no base64). GAME FROM SCRATCH: nowa (plansza, zrecznosciowa, logiczna) instead of a target creates a package from the Klyo Kit skeleton and applies edits right away; the response carries upload_id. UNDO: before every edit a checkpoint auto-N is created (it is in the response); revert goes back to it or to a named checkpoint, discard abandons the whole workshop for good; players see none of this. Limits: a file from content up to 1 MB, a call up to 256 KB and 20 edits, 3 open workshops per account; a workshop with no changes for 7 days expires, and the version players have stays untouched.

Examples: • Change the board colour in style.css of my game czworki • In js/gra.js of slice-rush change the speed from 4 to 6 • Add a levels.json file with three levels to the package in the waiting room

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nowaNoA game from scratch, without a ZIP: in the same call a package is created from the Klyo Kit skeleton (as in klyo_game_scaffold) and `edits` change it right away (you overwrite skeleton files without `expected_hash`). The response carries `upload_id` for the next calls. Instead of `slug` and `upload_id`. Values: `plansza` (board game with turns), `zrecznosciowa` (arcade), `logiczna` (puzzle).
slugNoGame address (from klyo_my_games). Give this or `upload_id`.
editsNoChanges; applied all or none. Each: `path` and one of three: `old_string` with `new_string`, `content` or `delete: true`.
revertNoReturn the workshop to a checkpoint (`auto-N` from an edit response or a name from `checkpoint`; the list is in klyo_game_files). Stands alone, without `edits`. The state before the revert is saved as a checkpoint too. Players see nothing: this is not a release rollback.
discardNoAbandon the workshop: the game loses the waiting version from the workshop (the version players have is untouched), a package returns to the files from its ZIP. Stands alone, without `edits`.
upload_idNoA waiting-room package, when there is no game yet; klyo_publish_game later releases it with these edits.
checkpointNoA named workshop checkpoint (for example premium-ui-v1): a snapshot of the state BEFORE the changes of this call; may stand alone, without `edits`. An automatic `auto-N` checkpoint is created before every edit anyway.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say the tool is destructive and not read-only. The description goes far beyond this: it explains the workshop copy, that players keep the old version until release, all-or-nothing application, conflict behavior with `expected_hash`, the klyo check, checkpoint/revert/discard semantics, expiry, and limits. This is rich, useful behavioral 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 description is long but dense and well-organized, with labeled sections (UNDO, Limits) and examples at the end. It front-loads the core editing behavior before alternates and edge cases. Some repetition with the schema exists, but most content earns its place.

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 complex 7-parameter tool with no output schema, this description is nearly complete: it covers target selection, edit modes, uploads, atomicity, conflict handling, undo, release flow, and limits. It names the key response artifacts (`upload_id`, `auto-N` checkpoint) but does not fully describe the response shape, which is the main gap.

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?

The input schema already covers 100% of parameters with detailed descriptions, so the baseline is 3. The description adds extra semantic value by explaining relationships: `slug` vs `upload_id`, `expected_hash` conflict prevention, `from_upload` as a no-base64 alternative, and `nowa` applying edits in the same call. It doesn't enumerate every parameter, but the schema handles that.

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 states a specific verb and resource: 'Edits a game's text files... without a ZIP' and defines the targets (`slug` or `upload_id`). It also differentiates this from release, publish, and upload tools by explaining the workshop workflow. The examples reinforce the intended actions clearly.

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?

The description explicitly routes usage: game `slug`, waiting-room `upload_id`, or `nowa` for a game from scratch. It names the follow-up tools (klyo_release_version, klyo_publish_game) and the upload mechanism (klyo_upload_package), giving an agent clear when-to-use and when-to-hand-off guidance.

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.