VidGuy

Publish a playable game

publish_playable

Idempotent

Deliver one version of a game built with the playable workflow (get_workflow_instructions {workflow:"playable"}): copies the master HTML and the source zip from the workspace, re-checks the master (at most 5 000 000 bytes, its sha256 equals verdictSha256 from validate.py --final, the bake line once and first, no , equals title) and returns a private play link (/play/...) the user can open and share. Pass playableId to add a version to an existing game; re-publishing a version number replaces it. Poster, icon and video go in as keys from media_confirm. Free; never makes the game public by itself.

Input Schema

Name	Required	Description
`slug`	Yes	The game's slug (lowercase letters, digits, dashes)
`title`	Yes	Byte-identical to CONFIG.meta.title and the <title>
`params`	No	__game.paramsValues()
`prompt`	No	The user's game prompt as given (the text after /playable, without the VidGuy MCP line, MEDIA or INPUTS), so the gallery can offer Recreate
`iconKey`	No	media_confirm key of the icon image
`locales`	No	Locales read from the built file, en first
`version`	Yes	v01, v02, ...
`gameType`	No	The host's game_type input, when given
`htmlPath`	Yes	Workspace path of the master HTML, e.g. ~/work/playable/<slug>/<slug>-v01.html
`presetId`	No	The preset id, e.g. runner
`settings`	No	__game.settingsValues()
`videoKey`	No	media_confirm key of the gameplay video, when one was made
`dimension`	No	The host's dimension input, when given
`posterKey`	No	media_confirm key of the poster image
`playableId`	No	Existing game to add this version to (from an earlier publish)
`paramsSchema`	No	__game.paramsSchema()
`sourceZipPath`	Yes	Workspace path of <slug>-v<NN>-source.zip
`verdictSha256`	Yes	sha256 from the VERDICT line of validate.py --final on this exact file

Output Schema

Name	Required	Description	Default
`playUrl`	No
`version`	No
`playableId`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

changedInput schema / properties / prompt / description

Previous value: -"The user's game prompt as given (the text after /playable), so the gallery can offer Recreate"New value: +"The user's game prompt as given (the text after /playable, without the VidGuy MCP line, MEDIA or INPUTS), so the gallery can offer Recreate"

Changed2 schema fields changedOct 27, 2026

addedInput schema / properties / dimension

Added value: +{
+  "description": "The host's dimension input, when given",
+  "enum": [
+    "2d",
+    "fast_3d",
+    "3d"
+  ],
+  "type": "string"
+}

addedInput schema / properties / prompt

Added value: +{
+  "description": "The user's game prompt as given (the text after /playable), so the gallery can offer Recreate",
+  "maxLength": 4000,
+  "type": "string"
+}

AddedOct 27, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description discloses the whole validation gate: 5,000,000-byte cap, sha256 must match verdictSha256, bake line once and first, no <script src>, <title> equals title. It also states the return value (a private /play/... link), the replacement behavior on re-publish, and that poster/icon/video come from media_confirm keys, which the annotations do not cover.

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 core action and the private-link outcome are front-loaded, and every clause about validation and versioning earns its place. It is denser and more run-on than ideal for an 18-parameter tool, but nothing is wasted.

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 an 18-parameter mutation with a full input schema and an output schema, the description supplies the critical validation and idempotency constraints plus the return-link behavior that an agent needs to call it correctly. The remaining per-field detail is legitimately left to the schema, so coverage is strong rather than exhaustive.

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%, so the baseline is 3. The description adds real meaning on top: playableId's purpose, the replacement semantics of version, and the origin of the media keys. It does not document the remaining 13 parameters (slug, locales, params, settings, etc.), leaving that entirely to the schema, so it stops short of a 5.

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 names a specific verb (deliver/publish) and resource (one version of a game built with the playable workflow), and it explains exactly what the tool does mechanically: copies the master HTML and source zip, re-validates, and returns a private play link. No sibling tool does this, and the description makes the scope unambiguous.

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

Usage Guidelines4/5

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

It gives strong when-to-use context: the workflow is first reached via get_workflow_instructions {workflow:'playable'}, playableId is used to add a version to an existing game, and re-publishing a version number replaces it. It also clarifies that the game is never made public automatically. There is no explicit 'when not to use' or named alternative, which keeps it below a 5.

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

All VidGuy tools Inspect

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

Need Help?