html5-games-token-saver
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| cg_build_checkA | Static portal checks of a built game or its zip: size, file count, index.html at root, absolute paths, resources from foreign hosts, zip slashes, SDK version. No browser, milliseconds. |
| cg_sdk_sessionB | Plays the build in an emulated CrazyGames frame with an SDK emulator, then idles and hides the tab. Verdicts for gameplay pairs, pause on windows, SDK reads while idle, autosave, save on hide, localStorage, sound during ads, rewarded cooldown, initial download, console errors. |
| cg_frame_auditB | Measures the DOM in each portal frame size at boot, at every check step and at the end: windows inside the frame, reachable controls, rendered text size, rewarded vs no-ad button size, page overflow, scrollers without a custom bar on phones. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool targets a different validation phase—static build checks, SDK/runtime behavior, and DOM/layout measurement—with no overlapping scope. Descriptions clearly delineate what each covers.
All tools share the cg_ prefix and snake_case, forming a predictable namespace. However, they use noun phrases rather than a verb_noun pattern, so naming is consistent but not action-oriented.
Three tools is on the low side but each covers a broad, distinct area of game validation (static, SDK, frame). The count is reasonable for a focused audit suite, though additional specialized checks would not be unexpected.
Covers static build checks, runtime SDK behavior, and layout auditing, forming a solid validation surface for HTML5 game portals. Minor gaps could include performance/network diagnostics or automated fix suggestions, but core workflows are addressed.