Skip to main content
Glama

klyo games: publish HTML5 browser games

by pl.klyo
OverviewDiscussionsAdmin

Read a game's files

klyo_game_files
Read-onlyIdempotent

Your game's files to read, without a ZIP from the owner. Target: a game's slug or a waiting-room package's upload_id. Without path you get the list (path, size, whether it is text, hash); with path, the content of one text file, up to 200 KB at a time (read further with from_line, narrow with lines); with changes: true, what changed in the waiting version compared with the version players have: how much code, visuals and sound (the same numbers the studio shows at “Release”) and the line differences. When the game has a waiting version (a workshop from klyo_game_patch or a new package) you read that one; otherwise the version players are playing. Pass the hash field as expected_hash to klyo_game_patch. Images and sounds are not returned as content, only their size. Read-only.

Examples: • Show the files of my game czworki • Read js/gra.js from lantern-thief starting at line 200 • What changed in the waiting version of slice-rush?

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoFile to read, relative to the game, for example js/gra.js. Without this field you get the file list.
slugNoGame address, for example lantern-thief (from klyo_my_games). Give this or `upload_id`.
linesNoMaximum number of lines (reading stops at 200 KB anyway).
changesNoTogether with the list: what changed in the waiting version compared with the version players have.
from_lineNoLine to start reading from (default 1).
upload_idNoA waiting-room package (from klyo_upload_package), when there is no game yet.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as safe, so the description adds value by explaining exactly what is read (text files, not images/sounds), size limits (200 KB), pagination (from_line, lines), and how it selects the version (waiting vs. players). This goes beyond the annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: it starts with the core purpose, explains the different modes, then provides concrete examples. Every sentence adds value, and the examples are practical for an agent to understand the tool's usage patterns.

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 read-only tool with comprehensive schema descriptions, the description covers all essential behavioral details: file list format, content reading constraints, changes comparison, version selection, and hash usage. No output schema exists, but the tool's return values are implicitly described, making it complete for agent invocation.

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?

The schema covers all parameters with descriptions (100% coverage), so the description doesn't need to repeat them. However, it adds context about how parameters interact (e.g., path vs. no path, changes with list, hash usage) and clarifies optionality, which slightly exceeds the schema's baseline.

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 states the tool reads a game's files, with a specific verb and resource, and distinguishes between reading the file list vs. file content vs. changes. It also differentiates from siblings by focusing on reading rather than patching or uploading.

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 explains when to use the tool (to read files from a game or waiting-room package), how to use it (with slug or upload_id, with or without path), and provides examples for common use cases. It does not explicitly mention alternatives, but its unique purpose is clear given the sibling list.

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

All klyo games: publish HTML5 browser games toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources