Create a game

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

The annotations only provide false hints (not read-only, not idempotent, not destructive), so the description carries the behavioral disclosure burden. It adds meaningful non-obvious behaviors: creation always lands as a draft, the slug is minted from the title, and the slug never changes because links outlive titles. This is valuable beyond what the schema reveals, though response format is not disclosed.

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

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

The description is compact: four sentences, front-loaded with the core action and draft status, followed by a scannable pipeline. Every sentence contributes useful information; there is no filler or restatement of schema details.

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

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

Given the 11 richly documented parameters and minimal annotations, the description covers the critical gaps: draft semantics, slug immutability, and the intended workflow. The main omission is the absence of an output schema and any description of the response shape, so the agent must infer that the created game's identifier is returned for subsequent update/build calls.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema describes all 11 parameters at 100% coverage, which sets a baseline of 3. The description adds value beyond the schema by clarifying that only title is required and, more importantly, that the slug is derived from the title and is immutable. That extra semantic link justifies a score above baseline.

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

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

The description opens with a specific verb and resource: 'Creates a game on your account.' It further differentiates from siblings by stating the result always lands as a draft and that publishing is a separate act, so an agent can immediately tell create_game apart from publish_game and update_game.

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

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

The description gives clear usage context: only title is required, the game is always created as a draft, and publishing is deliberately separate. The typical flow (create_game → upload_game_build → define_achievements → add_screenshot → set_cover → publish_game) is explicit guidance. It does not name update_game as the alternative for existing games, but the boundary is strongly implied.

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