Update a game

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

Annotations are sparse, so the description carries the behavioral burden — and it delivers. It discloses partial-update semantics, empty-string clears optional URLs, the slug is immutable, and updating a published game won't take it offline. These are exactly the non-obvious behaviors an agent needs to know before calling.

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?

Three dense sentences cover the essential behavioral contract with zero filler. The 'genuine partial update' lead-in is immediately useful, and each sentence earns its place by communicating a distinct constraint or consequence.

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?

For a 12-parameter mutation tool with no output schema, the description plus fully documented schema is nearly complete. It covers the key update semantics, clearing behavior, slug invariance, and publishing status. It doesn't describe the response shape, but with no output schema to match against, the missing piece is minor.

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?

With 100% schema description coverage, the baseline is 3, but the description adds cross-cutting meaning beyond the schema: what a partial update means for all parameters, the sentinel behavior of empty strings for optional URLs, and immutability of the slug. This is more than the schema provides, though individual parameter details are already well covered there.

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 names a specific resource and operation ('update a game') and immediately sharpens it with 'a genuine partial update,' which separates it from whole-object replacement or publishing workflows. It also calls out immutable/preserved traits (slug, published state) that make the tool's scope unmistakable.

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?

It gives actionable usage guidance by explicitly preferring set_cover for cover uploads and noting that upload_game_build sets the hosted playMode. It could be more explicit about when to choose update_game over create_game, publish_game, or delist_game, but it provides enough context for common alternatives.

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