Skip to main content
Glama

YouGame

by co.yougame

publish_game

Idempotent

Publishes a staged build as a game on YouGame, live at once, skipping the creator's review. Needs the creator's API key and their explicit instruction: the normal path is prepare_submission, which hands the creator a review link where they press Publish themselves. Call this only when the creator explicitly told you, in their own words, to publish without opening the review page ("looks good" about a draft is not that); never because it is faster. After prepare_submission the uploadId alone is enough (every other field keeps the draft's value); otherwise pass the listing fields.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNo1–80 characters.
genresNoUp to 3; the first is the main one.
matureNoTrue when the game is for adults only (blood and gore, strong language, mature themes). Ask the creator if the game's content leaves it unclear.
mobileNoTrue only when the game plays with touch (pointer events, on-screen controls, 44 px targets, fills the screen). Lists it for phones.
api_keyNoOnly when the key could not be set as the Authorization header of the MCP connection: the creator's API key (yg_…). Prefer the header (or the YOUGAME_API_KEY environment variable): a key passed here ends up in the agent's transcript and tool logs.
controlsNoHow the game is played. Default Keyboard.
paywallsNoThe paywalls the build charges with YouGame.coins.charge(key), each priced by the creator: ask them for the price and kind. Leave it out when the game charges nothing.
uploadIdYesFrom the upload reply (32 hex characters).
max_scoreNoOptional: the highest score the game can produce. Scores above it are held for review. Work it out from the game's scoring, or leave it out.
play_modeNosingle (solo only), multiplayer (online only), or both. Default: multiplayer when the build calls findMatch, else single.
thumbnailNoThe path, inside the build, of a 16:9 PNG/JPG/WebP/GIF under 8 MB for the game's card. Not needed again once one was sent with PUT /api/agent/media.
descriptionNoUp to 1000 characters: what the game is and how to play. Write it from the game.
screenshotsNoOptional: up to 8 image paths inside the build.
creator_approvedYesTrue only when the creator explicitly told you, in their own words, to publish this game without opening the review page. Approval of a draft summary in chat does not count. Never assume it; the tool refuses without it.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed8 schema fields changed
    • changedInput schema / properties / controls / description
      Previous value: -"Default Keyboard."New value: +"How the game is played. Default Keyboard."
    • addedInput schema / properties / creator_approved
      Added value: +{
+  "description": "True only when the creator explicitly told you, in their own words, to publish this game without opening the review page. Approval of a draft summary in chat does not count. Never assume it; the tool refuses without it.",
+  "type": "boolean"
+}
    • changedInput schema / properties / description / description
      Previous value: -"Up to 1000 characters: what the game is and how to play."New value: +"Up to 1000 characters: what the game is and how to play. Write it from the game."
    • changedInput schema / properties / mature / description
      Previous value: -"True when the game is for adults only."New value: +"True when the game is for adults only (blood and gore, strong language, mature themes). Ask the creator if the game's content leaves it unclear."
    • changedInput schema / properties / max_score / description
      Previous value: -"Optional: the highest score the game can produce. Scores above it are held for review."New value: +"Optional: the highest score the game can produce. Scores above it are held for review. Work it out from the game's scoring, or leave it out."
    • addedInput schema / properties / paywalls
      Added value: +{
+  "description": "The paywalls the build charges with YouGame.coins.charge(key), each priced by the creator: ask them for the price and kind. Leave it out when the game charges nothing.",
+  "items": {
+    "properties": {
+      "key": {
+        "description": "The key the game passes to YouGame.coins.charge.",
+        "type": "string"
+      },
+      "kind": {
+        "description": "unlock: pay once, owned forever. play: pay every time.",
+        "enum": [
+          "unlock",
+          "play"
+        ],
+        "type": "string"
+      },
+      "label": {
+        "description": "What the player sees on the purchase sheet, up to 60 characters.",
+        "type": "string"
+      },
+      "price": {
+        "description": "Whole coins, 1 to 5000.",
+        "type": "number"
+      }
+    },
+    "required": [
+      "key",
+      "label",
+      "price",
+      "kind"
+    ],
+    "type": "object"
+  },
+  "maxItems": 20,
+  "type": "array"
+}
    • changedInput schema / properties / thumbnail / description
      Previous value: -"Strongly recommended: the path, inside the build, of a 16:9 PNG/JPG/WebP/GIF under 8 MB to show on the game's card. Add one to the build folder before zipping if the game has none."New value: +"The path, inside the build, of a 16:9 PNG/JPG/WebP/GIF under 8 MB for the game's card. Not needed again once one was sent with PUT /api/agent/media."
    • changedInput schema / required
      Previous value: -[
-  "uploadId",
-  "title"
-]New value: +[
+  "uploadId",
+  "creator_approved"
+]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (mutation, idempotent, non-destructive), the description discloses the consequential behaviors: the game goes live immediately and bypasses the human review gate, the tool refuses without explicit creator consent, and passing api_key in the payload 'ends up in the agent's transcript and tool logs.' These are materially useful behavioral disclosures that annotations alone do not convey, and nothing contradicts the idempotentHint.

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?

Five sentences, all front-loaded: the action and its most important consequence come first, then the alternative path, then the strict consent condition, then the parameter shortcut. No filler; even 'never because it is faster' earns its place as a guard against anticipated misuse.

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 safety-sensitive 14-parameter mutation that goes live publicly, the description covers the decision boundary, the consent requirement, and the parameter shortcut, while the fully documented schema handles field semantics and defaults. The only real omission is the return value or confirmation shape, which is minor because the tool's risk profile and invocation rules are completely specified.

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 genuinely new inter-parameter semantics: 'After prepare_submission the uploadId alone is enough (every other field keeps the draft's value); otherwise pass the listing fields.' That relationship — when one required field suffices versus when the whole listing must be passed — is nowhere in the per-field schema and materially changes how the agent fills the call.

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?

Opens with a specific verb and resource — 'Publishes a staged build as a game on YouGame' — and immediately adds the distinguishing consequence 'live at once, skipping the creator's review.' That phrase sets it apart from the sibling prepare_submission, which hands the creator a review link, so the agent can tell the two apart from the first sentence alone.

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?

Names the alternative explicitly: 'the normal path is prepare_submission, which hands the creator a review link where they press Publish themselves.' It then states a strict when-to-use rule — only when the creator said, in their own words, to publish without the review page — reinforced by a counter-example ('looks good' about a draft is not that) and a standing prohibition ('never because it is faster').

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

All YouGame toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

The tools separate into clear workflows: documentation lookup (search/fetch/get_publish_guide/get_sdk_reference), build validation, and the publishing lifecycle (prepare_submission, publish_game, update_game), so most purposes are unambiguous. The four documentation tools overlap somewhat, though their descriptions distinguish browsing a full document from fetching a specific section.

Naming Consistency4/5

Most tools follow a verb_noun snake_case pattern (check_build, prepare_submission, publish_game, update_game), and the documentation tools consistently use get_. Minor deviations like the bare verbs fetch and search and the noun-phrase my_games keep it from being perfectly uniform.

Tool Count5/5

Nine tools is well within the ideal range, and each tool occupies a clear place in the YouGame workflow: documentation, build checking, submission, publishing, updating, and listing published games. No tool feels redundant or superfluous.

Completeness4/5

The set covers the full lifecycle from build validation to draft review to live publication and version updates, plus documentation search and a way to list existing games. Missing operations like unpublishing/deleting a game or retrieving details for a single game are minor gaps that can be worked around with my_games and the review-link flow.

Resources