Skip to main content
Glama
Alex88Ryabov

html5-games-token-saver

by Alex88Ryabov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

html5-games-token-saver

MCP server that checks a built HTML5 game against the CrazyGames portal rules and answers with dense JSON: a list of failures, warnings and rules it could not exercise, instead of screenshots and one-off Playwright scripts in the agent context.

Install

claude mcp add html5-games-token-saver -- npx -y @alex-apps/html5-games-token-saver

The game needs Playwright with Chromium (npm i -D @playwright/test && npx playwright install chromium); the server takes it from the game's node_modules. Build the game before a check: the tools read dist, not src.

Related MCP server: flowcheck

Tools

Tool

What it does

Time

cg_build_check

Size, file count, index.html at root, absolute paths, resources from foreign hosts, zip slashes, SDK version, viewport meta, user-select, stale build. Dist folder or release zip.

ms

cg_sdk_session

Plays the build in an emulated portal frame with an SDK v3 emulator, idles, hides the tab. Verdicts below.

~10 s + idle

cg_frame_audit

DOM in each frame size at boot, at each check step, 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.

seconds per size

cg_sdk_session rules: first gameplayStart, bytes loaded before it, loading order, start/stop pairs, a pause on every window and a resume on close, an SDK member hit repeatedly (a render loop or a per-second timer), SDK reads with no input, autosave every 30 s, save on hide, localStorage writes on the portal, sound during an ad, rewarded cooldown, banner refresh, console errors, 404s inside the frame, requests to foreign hosts, SDK members the emulator does not implement.

A rule the run could not reach comes back in unchecked with the reason; it is never reported as a pass.

How it emulates the portal

No server and no port. page.route answers www.crazygames.com/game/<slug> with a page holding an iframe of games.crazygames.com/en_US/<slug>/index.html, serves the build from disk (folder or zip) under that path, and serves the SDK emulator at sdk.crazygames.com. A host check or an iframe check in the game sees the portal. Foreign requests get an empty 204 and are listed. A probe injected before the game scripts records SDK calls and property reads, localStorage writes, windows opening and closing (role=dialog, dialog[open], aria-modal), and the audio level tapped in front of AudioContext.destination, so the mute check works for any engine.

Playwright is taken from the game's node_modules (its e2e already installs it and its browsers), then from next to this package.

Scenario

The only game-specific part. cg-scenario.json in the game root, or the same fields as tool arguments:

{
  "init": "window.__mtDebug = true",
  "query": "?debug=1",
  "dialog": "[role=dialog]",
  "steps": [
    { "waitFor": "data-testid=settings-open" },
    { "click": "data-testid=settings-open" },
    { "check": "settings" },
    { "tap": [0.005, 0.005] },
    { "press": "Escape" },
    { "eval": "window.__mt.requestMidgame()" },
    { "rewardedTwice": "[data-testid=bonuses-modal] button:has-text(\"Watch\")" },
    { "wait": 2500 }
  ]
}

Selectors are Playwright selectors inside the game frame; taps are viewport fractions, so one scenario serves every frame size and canvas games. A click is a player's click at the element's centre (game buttons pulse and never look stable to Playwright); on phone sizes clicks and taps are touches. waitFor takes timeoutMs for slow 3D boots. check holds the screen 4.5 s in a session (a per-second timer shows) and measures in the audit, after finite CSS animations end. rewardedTwice watches a rewarded ad, then clicks the same button again at once.

Windows and their gameplayStop are matched by order, not by clock: a 3D game under SwiftShader sent the stop 10 s after the click and showed the window 3.5 s later.

Verified on

  • A fixture game (fixtures/mini-game) where each reviewer rule is broken by a query flag: the clean run passes every rule, each flag fails its rule (npm run smoke).

  • Muscle Titans 1.7.0 and 2.0.1, built from git before the fixes for two reviewer emails: the session finds inviteLink called every second, the save copy in localStorage, autosave once a minute, unlimited rewarded ads, isUserAccountAvailable read every second; the audit finds the missing iOS scrollbar. 2.0.2, the fixed version, passes all of them. Not checkable by the tool: the midgame countdown text and the banner suggestion.

  • Blocky Barber and TowerDefence (three.js; TowerDefence renders over a second per frame under SwiftShader): scenarios open every window and both pass; their ads are off before Full Launch, so the ad rules stay unchecked.

Limits

  • Chromium under SwiftShader: WebGL works, timings are slower than a real GPU.

  • The portal's real iframe allow list is not known; the emulated one is permissive.

  • textSize uses 12 px, the owner's threshold, not a docs number.

  • Custom iOS scrollbars are recognised by class names and roles; a miss is a warning.

  • A canvas-drawn interface cannot be measured from the DOM; the audit says so in unchecked.

  • Unity and Godot export plugins are assumed to call the same JS SDK; not verified.

Commands

npm test       build + unit tests (node:test)
npm run smoke  real MCP client over stdio against the fixture game
node tools/run.mjs build|session|audit <path> [...]  one tool without a client

Available Tools

3 tools
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.

NameRequiredDescriptionDefault
pathYesGame root, its build folder (dist, build/web) or the release zip

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose two useful traits: no browser is launched and it runs in milliseconds (static, cheap, non-interactive). However, it never states that this is a read-only inspection, what severity/result shape it produces, or what happens on failure, which are the traits an agent needs for a checker tool.

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?

A single dense sentence, front-loaded with the purpose then the distinguishing trait ('No browser, milliseconds'). Every clause earns its place; nothing is padded.

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 one-parameter, no-output-schema tool the description is nearly self-sufficient: the list of checks effectively tells the agent what is being validated. It stops short of describing the result format or severity levels, but that is a minor gap given the low complexity.

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?

Schema coverage is 100% and the single 'path' parameter already documents that it accepts the game root, a build folder (dist, build/web), or the release zip. The description only echoes 'a built game or its zip' and adds no syntax or format detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb + resource: 'Static portal checks of a built game or its zip', followed by a concrete enumeration of what is inspected (size, file count, index.html at root, etc.). This clearly separates it from a runtime concern, but it does not name or contrast with the siblings cg_sdk_session or cg_frame_audit, so differentiation is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'No browser, milliseconds' implies a fast pre-flight/static context and implicitly contrasts with the runtime siblings, but there is no explicit when-to-use statement, no prerequisites, and no when-not condition. Usage is implied rather than stated.

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

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.

NameRequiredDescriptionDefault
initNoJS run in the game frame before its scripts, e.g. a debug flag
pathYesGame root, its build folder (dist, build/web) or the release zip
queryNoAppended to the game URL, e.g. ?debug=1
shotsNoSave a PNG of each failing point to the temp folder and return the paths
sizesNoWxH, m suffix for a touch phone
stepsNoRun after boot, in the game frame: {click:selector} {tap:[x,y] viewport 0..1} {press:key,holdMs?} {wait:ms} {waitFor:selector,timeoutMs?} {eval:js} {check:label} {rewardedTwice:selector}. Default: steps of cg-scenario.json
dialogNoCSS selector of a window; default role=dialog, dialog[open], aria-modal
engineNochromium
minTextPxNo

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the sampling cadence and the concrete metrics captured (overflow, text px, rewarded vs no-ad button size), but says nothing about side effects such as launching a browser, writing PNGs to temp, or the shape of the returned report.

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?

A single front-loaded sentence with the verb and scope first, followed by a tight colon list of measured properties. Dense but every clause carries information; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with no output schema and no annotations, the description explains what is measured but not what is returned (report structure, failure details) nor how it relates to sibling tools. Adequate for orientation, incomplete for correct 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?

Schema description coverage is 78% and the per-parameter descriptions are detailed (init, path, query, sizes suffix 'm', step verbs). The description adds no parameter-level meaning beyond the schema, so baseline 3 is appropriate; engine and minTextPx remain undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb (measures) and resource (the DOM in each portal frame size), plus the exact sampling points (boot, each check step, end). It is clearly a responsive-layout audit tool, though it never contrasts itself with siblings cg_build_check or cg_sdk_session.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states when the tool samples internally, but never when an agent should choose it over cg_build_check or cg_sdk_session, and lists no prerequisites or exclusions. Usage must be inferred from the measurement list.

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

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.

NameRequiredDescriptionDefault
initNoJS run in the game frame before its scripts, e.g. a debug flag
pathYesGame root, its build folder (dist, build/web) or the release zip
queryNoAppended to the game URL, e.g. ?debug=1
stepsNoRun after boot, in the game frame: {click:selector} {tap:[x,y] viewport 0..1} {press:key,holdMs?} {wait:ms} {waitFor:selector,timeoutMs?} {eval:js} {check:label} {rewardedTwice:selector}. Default: steps of cg-scenario.json
dialogNoCSS selector of a window; default role=dialog, dialog[open], aria-modal
engineNochromium
adOutcomeNoHow the emulated ad endsfinished
idleSecondsNoNo-input stretch in play; autosave needs >= 32

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose meaningful behavior: a play -> idle -> hide-tab lifecycle, an emulated ad with configurable outcome, and the categories monitored (autosave, save on hide, sound during ads, console errors). It omits key operational traits such as runtime (the default 35s idle, up to 300), whether it launches a browser, and whether/where it writes a report.

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 first sentence front-loads the action and lifecycle, which is the most important information. The second sentence is a comma-separated heap of check names, but each item is substantive and tells the agent what the session will cover, so the density earns its place rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter harness with no annotations and no output schema, the description explains the session flow and the verdict categories but never says what the return value looks like, where results are written, or how long a run takes. It is adequate to recognize the tool but leaves an agent unable to predict the call's cost or result shape.

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?

Schema description coverage is 88%, so the schema already documents path, init, query, steps, dialog, engine, adOutcome and idleSeconds in detail (including the autosave >= 32 hint). The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb and resource: play the build in an emulated CrazyGames frame with an SDK emulator, then idle and hide the tab, producing verdicts. The verdict list further pins down the scope (gameplay pairs, autosave, rewarded cooldown, console errors). It is clear, but it never names cg_build_check or cg_frame_audit, so the agent must infer the split from the sibling names alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the enumeration of SDK/behavioral verdicts signals this is the tool for behavioral SDK verification during a simulated session. There is no explicit when-to-use versus cg_build_check or cg_frame_audit, and no stated prerequisites or exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedcg_build_check
    • First observedcg_frame_audit
    • First observedcg_sdk_session
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.6/5.0

Scored across 3 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • ui-assert

    Aakashpai
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables coding agents and CI to verify rendered web UIs against design token usage, layout constraints, and accessibility rules, returning concise pass/fail verdicts with actionable findings.
    MIT

  • flowcheck

    kadessovb02
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables coding agents to validate web pages and run repeatable JSON browser scenarios, returning pass/fail results with local Playwright evidence such as screenshots, traces, and JUnit XML.
    4 npm
    1
    Apache 2.0

  • Game OCP MCP

    imozkandev
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI clients to validate game level progression data, audit localization packs for missing translations and dynamic-token mismatches, and run deterministic evaluations of generated puzzle or notification content.
    1
    MIT

  • Mobile Game Fixer MCP

    imozkandev
    A
    license
    Not graded
    quality
    C
    maintenance
    Provides deterministic, offline, sourced resolutions for 44 mobile game development problems spanning performance, memory, rendering, store policies, IAP billing, crash vitals, live-ops emergencies, and store-policy deadlines, along with pre-launch checklists and launch-day runbooks. It also statically audits project directories for Google Play and App Store compliance, including target SDK, 16 KB ELF alignment, privacy manifests, and secret-file exposure, without any network calls or shell execution.
    MIT