klyo games: publish HTML5 browser games

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

Annotations only indicate non-read-only and non-destructive, leaving the tool's write nature implied. The description adds valuable behavioral details: the post appears immediately with no moderation queue, and linking to a game adds a play button. This goes beyond the annotations and helps the agent anticipate the outcome.

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, with a clear main purpose stated first, followed by a key behavioral note and three illustrative examples. It avoids redundancy and is well-organized for quick scanning, though it could be slightly more streamlined.

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 6-parameter tool, the description covers the core purpose, the immediate visibility, the linking effect, and typical use cases. It does not detail error handling or return values, but the absence of an output schema and the simplicity of the operation make this acceptable. Overall, an agent can confidently invoke the tool.

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?

Schema coverage is 100%, so the baseline is 3. The description adds semantic value beyond the schema by explaining the effect of gra_slug (readers get a play button) and by contextualizing the post types with examples. This extra guidance justifies a 4.

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 clearly states the tool writes a post in the klyo games community and enumerates the specific post types (question, playtesters, launch, showcase). This is a distinct resource and verb, and it is unambiguous compared to sibling tools that all handle game management rather than community posting.

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 provides concrete examples of when to use the tool (launch, playtesting, showcase) and explains the immediate visibility and linking behavior. It does not explicitly name alternative tools or exclusions, but since no sibling tool serves the same purpose, the usage context is sufficiently clear.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false; the description goes well beyond by stating the save replaces the previous text and changes the public page immediately, that saves pass through the same validation as the studio, and that the calling assistant (not klyo) authorizes the write. The read-mode behavior is also disclosed, resolving a real ambiguity left by the non-readOnly annotation.

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?

Front-loads the resource and then the write/read contract, with no filler sentences. It is dense — capitalized 'YOU WRITE', interleaved Polish field names, and a trailing example block make it slightly harder to scan than needed for a 3-parameter tool.

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?

No output schema exists, and the description compensates: it says exactly what the read mode returns (current card, the released games as the only permitted source material, and the rules) and references the `do_poprawy` response field. Combined with the consent gate and mutation warning, an agent has everything needed to call it safely.

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?

Schema coverage is 100% and the schema already documents the tagline length/title-template rules, the `<pl>/<en>` tagging, the omit-to-keep behavior, and the `wymaga_nazwy` requirement. The description restates these rather than adding new semantics, so the 3 baseline applies.

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?

States the concrete resource (the developer profile card on games.klyo.pl: 'about me' plus the tagline) and immediately clarifies the dual mode — read when `o_mnie`/`haslo` are omitted, write when supplied. It does not explicitly contrast itself with siblings like `klyo_update_game` or `klyo_add_post`, but it does describe the handoff to `klyo_publish_game`, so an agent can place it.

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?

Gives explicit mode selection rules (no fields = read, fields = save, omitted field = unchanged), a mandatory workflow gate ('FIRST show the text to the owner and save only with their consent'), a content constraint ('Do not invent facts about the person'), and a cross-tool retry instruction tied to `klyo_publish_game` error `wymaga_nazwy`.

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

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

Annotations already indicate destructiveHint:true and readOnlyHint:false, but the description adds substantial behavioral detail: the first call removes from catalogue and takes the page down while keeping the address, a second call removes it for good, and scores/reviews remain tied to the address. It also explains the non-game package path via `upload_id`, which is beyond what annotations convey.

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 a well-structured paragraph with examples, front-loaded with the primary action. It is somewhat verbose but every sentence contributes meaning—covering the two-step process, data persistence, and parameter selection. The examples at the end aid comprehension without redundancy.

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 destructive tool with no output schema, the description covers the key behavioral aspects: what happens on first and second calls, what data persists, and how to handle packages. A minor gap is that it does not explicitly state that `slug` and `upload_id` are mutually exclusive or that at least one is required, though the description strongly implies it. Overall, it provides sufficient guidance for an agent to call correctly.

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?

Schema coverage is 100% (both parameters have descriptions), but the tool description goes further by explaining the provenance of each parameter (e.g., `slug` from klyo_my_games, `upload_id` from klyo_upload_package) and the conditions under which each is used. This adds contextual value beyond the schema's own descriptions.

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 states a specific action: 'Take this account's game (`slug`) off the portal.' It clearly distinguishes this from siblings like klyo_update_game or klyo_publish_game by focusing on removal. The two-step deletion process is explained, making the tool's purpose unambiguous.

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 explicit usage context: 'Use it to clean up after a failed attempt, for example when two entries of the same game ended up in the waiting room.' It also clarifies when to use `slug` vs `upload_id` and notes that a second call on an already-down game permanently removes it. Examples illustrate common scenarios, leaving no ambiguity about when to invoke this tool.

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

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

Annotations only declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false. The description adds substantial context beyond them: the owner watches and submits, klyo runs no model and saves nothing (pure browser draft), and invalid fields return in `odrzucone` with reasons while `do_poprawy`/`formularz_otwarty` surface validation and form state. This tells the agent what actually happens on invocation.

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?

Front-loaded with the core purpose in the first sentence, followed by mode behavior, constraints and concrete examples — every paragraph earns its place. It is dense and the opening sentence is long, but there is no filler; a slightly tighter lead would make it a 5.

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 tool with a 24-field nested schema, no output schema and no required params, the description covers the workflow (open form → fill → owner submits), the validation feedback keys, and the scope exclusions. The agent has everything needed to call it correctly and interpret the interactive result.

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?

Schema description coverage is 100%, so baseline is 3; the description earns above baseline by explaining the two-mode semantics of `pola` (omit → discovery/field list, provide → live send) and the refusal/validation loop. It does not add field-level detail beyond the already exhaustive schema.

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?

States a precise verb and resource — types fields into the OPEN 'New game' form in the developer's studio — and immediately scopes it as a live draft the owner submits themselves. This distinguishes it behaviorally from the save/update siblings (klyo_update_game, klyo_game_patch) even without naming them. An agent can tell what this tool does and does not do.

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?

Explicit two-mode guidance: without `pola` you get the field list, allowed values and `formularz_otwarty` (whether the form is open); with `pola` fields are sent live. It states what must NOT be filled (questionnaire, statements, consents) and how to send corrections ('same tool'). Routing to klyo_game_translate for other languages is named in the schema, so the alternative path is clear.

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

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

Annotations declare destructiveHint=true and non-idempotent, and the description supplies the crucial detail behind that hint: 'Pass ONLY the fields you change... the fields you pass replace the current text.' It also discloses refusal codes (opis_en_wymagany, brak_hasla, nazwa_z_haslem) and that this path skips the safety check. It stops short of saying whether edits are reversible or take effect on the live page immediately, so a 4 rather than 5.

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?

Front-loaded with the differentiator (content, not package) before the language policy and examples, and the field enumeration is compact. The LANGUAGES paragraph partially repeats material that also lives in the `opis` and `jezyk_tekstu` schema descriptions, which is the only notable redundancy.

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 26-parameter, nested-object mutation with no output schema, the description covers partial-update semantics, alternatives, language rules and failure modes. It does not describe the response shape (which matters since no output schema exists), though it does reference the `do_poprawy` and refusal identifiers.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter rules the schema does not state on its own: the <en> (required, ≥25 words) / <pl> (+40 XP) tag policy, the prohibition on non-developer translations, and the role of `jezyk_tekstu` for name/tagline/controls. It also lists the field groups being edited, giving a useful map across 26 parameters.

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?

Opens with a specific verb+resource ('Change the CONTENT of a game that is already in the catalogue') and enumerates the exact fields it touches. It explicitly names the sibling it is not (`klyo_update_game`) and explains the boundary (package files vs. catalogue text), so an agent can route without opening either schema.

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?

States both when to use it ('a typo in the description should not cost' a re-run of the safety check) and when not to (replacing files → `klyo_update_game`; translating → `klyo_game_translate`). It also gives three concrete usage examples, which is more routing help than most definitions provide.

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

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

Annotations already cover readOnly/idempotent/non-destructive, so the description's 'Read-only' is redundant, but it adds real context beyond them: the rate limit on `sprawdz_google` ('at most once an hour per game'), the fact that funnel and click-map data are collected with NO code in the game, and the caveat that the player tag is stable only within this game. These are non-obvious behavioral traits that annotations do not carry.

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?

It is front-loaded with the verdict first and the follow-up action last, which is good. However the middle is a single dense wall of backticked Polish field names with no paragraph breaks or list structure, and some of it (e.g. re-explaining 'Read-only') does not earn its space. Readable but overstuffed.

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?

There is no output schema, so the description justifiably carries the full burden of documenting return values, and it does so thoroughly per dataset (each field's meaning, e.g. `odpada` = sessions lost at this step). The main gap is the lack of disambiguation from the similar `klyo_game_stats` sibling; otherwise it is complete enough to invoke correctly.

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?

Schema description coverage is 100%, so all three parameters are already documented in the schema (including `dni` and the URL-Inspection caveat on `sprawdz_google`). 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.

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

The description names a specific verb+resource (game analytics for the developer) and enumerates the concrete datasets returned: verdict, funnel (`lejek`), levels, events, click map, sessions, countries. That is far more specific than a title restatement. It does not, however, differentiate itself from the sibling `klyo_game_stats` or `klyo_game_diagnostics`, which an agent could easily confuse with this tool.

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 explicit sequencing ('read `_najpierw` first') and a follow-up workflow ('Fix what `_najpierw` says (klyo_fix_game, klyo_game_patch, a new version) and ask again after the next players'), plus three example questions. It stops short of stating when NOT to use it or how it differs from the overlapping `klyo_game_stats` sibling.

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

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

Beyond the annotations' readOnlyHint=false, the description discloses key behavior: frames are captured by the system once the game is live, the first call lists rather than mutates, and setting a mismatched cover can lead to the game being taken down. It also makes the no-custom-image policy explicit, which is a constraint an agent could not infer from the schema.

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 longer than minimal, but every sentence contributes a distinct fact: purpose, release timing, selection workflow, and content policy. It is front-loaded with the action and uses examples compactly; it could be tightened slightly, but nothing is filler.

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 two-parameter tool with no output schema, this definition covers the full call sequence, prerequisites, the source of frames, and the policy that governs acceptable covers. The examples also show natural user phrasings, leaving little ambiguity about how to invoke the tool.

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 schema already covers both parameters at 100%, so the baseline is 3. The description adds value by explaining that omitting 'klatka' returns a list of frame addresses and that the number selects one of those frames, with an example showing 'the second frame' as the argument.

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 action ('Set') and resource ('the tile players recognise the game by in the catalogue'), so the role of the tool is immediately clear. It also distinguishes klyo_game_cover from generic update tools by explaining its unique mechanism: covers must be screenshots from the running game, never custom images.

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 an explicit two-phase workflow: call without 'klatka' to list available frames, then call again with the chosen frame number. It also states the temporal precondition (frames exist only after klyo_publish_game) and the hard exclusion (no custom images), giving the agent clear when-to and when-not-to guidance.

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

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

It discloses a lot of genuine behavior: per-account concurrency (one measurement running, one queued), a 6-per-hour quota with a full measurement counting double, 14-day/24-hour/7-day retention rules, and the NIESPRAWDZONA/POMIAR_NIEAKTUALNY caveats. But it states 'Read-only.' while annotations declare readOnlyHint=false and the description itself documents `zmierz` starting a server-side measurement job that consumes quota — a self-inconsistent claim that can mislead an agent about side effects.

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?

A ~600-word, single-block wall of text that is not front-loaded: it leads with draft-version bookkeeping rather than the tool's function. It mixes English prose with untranslated Polish field names and interleaves four distinct topics (version selection, error reading, gate verdicts, Google visibility, measurement), making it hard to scan.

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 an 8-parameter tool with no output schema, the description does the heavy lifting: it enumerates the returned fields (`_najpierw`, `bledy_przegladarki`, `dopasowanie.uwagi[]` codes, `bramka.wynik` values, `widocznosc`) and explains what each verdict means. It is complete enough to call correctly, though disorganization and the 'Read-only' misstatement undercut it slightly.

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?

Schema coverage is 100%, so the baseline would be 3; the description adds cross-parameter semantics the schema does not spell out, e.g. `poprzednia_paczka` must accompany the new `upload_id` on its first preview, `sesja` must match the `?s=` marker used when opening the preview, and `pelny` only matters alongside `zmierz`. It leaves the odd 'klyo_update_game for games with a slug' line unexplained relative to the `slug` parameter.

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 tool is a diagnostics reader for a waiting-room package (`upload_id`) or a catalogue game (`slug`), returning missing files, JS errors, gate verdicts and screen-fit measurements. That purpose is discoverable, but the description opens with 'WAITING PACKAGE VERSIONS' workflow mechanics instead of a statement of what the tool is for, so the agent must reconstruct the purpose from scattered fragments. Sibling differentiation is only partial and partly confusing ('Use klyo_update_game for games with a slug').

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 real routing guidance: the prescribed order ('Order: open, play, ask; the other way round gives an empty answer'), the no-browser fallback (`zmierz: true`), the session-isolation recipe (`?s=` + `sesja`), and a pointer to klyo_fix_game for Google visibility fixes. What is missing is an explicit statement of when NOT to call this tool or which sibling to use for pure error checking versus publishing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as safe, so the description adds value by explaining exactly what is read (text files, not images/sounds), size limits (200 KB), pagination (from_line, lines), and how it selects the version (waiting vs. players). This goes beyond the annotations without contradiction.

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 well-structured: it starts with the core purpose, explains the different modes, then provides concrete examples. Every sentence adds value, and the examples are practical for an agent to understand the tool's usage patterns.

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 read-only tool with comprehensive schema descriptions, the description covers all essential behavioral details: file list format, content reading constraints, changes comparison, version selection, and hash usage. No output schema exists, but the tool's return values are implicitly described, making it complete for agent invocation.

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 schema covers all parameters with descriptions (100% coverage), so the description doesn't need to repeat them. However, it adds context about how parameters interact (e.g., path vs. no path, changes with list, hash usage) and clarifies optionality, which slightly exceeds the schema's 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 clearly states the tool reads a game's files, with a specific verb and resource, and distinguishes between reading the file list vs. file content vs. changes. It also differentiates from siblings by focusing on reading rather than patching or uploading.

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 explicitly explains when to use the tool (to read files from a game or waiting-room package), how to use it (with slug or upload_id, with or without path), and provides examples for common use cases. It does not explicitly mention alternatives, but its unique purpose is clear given the sibling list.

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

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

Annotations already flag destructive/non-idempotent writes, but the description adds substantial context beyond them: the workshop isolation model (players keep the old version), all-or-none application, conflict on `expected_hash` mismatch, integrity checks before release, and hard limits (1 MB/file, 256 KB/call, 20 edits, 3 workshops, 7-day expiry).

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?

Front-loaded with the core operation and the workshop concept before edge cases. It is dense and some sentences pack several rules (limits, checks, undo) together, which costs a little scannability, but nothing is genuinely off-topic for a tool of this complexity.

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?

No output schema exists, and the description compensates by noting the response carries an `auto-N` checkpoint and, for `nowa`, a `upload_id`. Combined with the conflict, limit and undo semantics, an agent has everything needed to invoke this correctly.

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?

Schema coverage is 100%, yet the description still adds meaning the schema cannot: the three mutually exclusive edit shapes, that `old_string` must occur exactly once unless `replace_all`, that `expected_hash` is required for existing files, and what each of `nowa`/`revert`/`discard`/`checkpoint` does operationally.

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?

States a specific verb and resource ('Edits a game's text files'), lists the exact handled extensions, and names the target identifiers (`slug` / `upload_id`). It explicitly distinguishes itself from siblings such as klyo_release_version, klyo_publish_game, klyo_game_files and klyo_game_scaffold.

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?

Gives explicit routing: use this for in-place text edits without ZIP, use `nowa` for a game from scratch, use klyo_upload_package + `from_upload` for binaries, use klyo_release_version/klyo_publish_game to release. It also names the undo path (`revert`/`discard`) and the conflict condition where edits are refused.

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

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

With annotations already declaring readOnly=false/openWorld=false/idempotent=false, the description adds substantial context beyond them: execution happens on the owner's device, the owner must click 'Allow' in the studio, they can watch and stop it, input is synthetic (not trusted events), pointer lock is simulated, and `request_id` makes retries idempotent. It also enumerates the `stan` status codes (brak_urzadzenia, karta_w_tle, zatrzymane, etc.) and the evidence/dowod_urzadzenia outcome.

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 opening sentence front-loads the purpose and the target/session model follows logically. It is dense and long, with a status-code list and evidence paragraph that tax readability, but for a 9-parameter tool with a nested step timeline most sentences carry real information.

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?

No output schema exists, so the description must carry the return-value burden — and it does: screenshots as image content, game state, `stan` codes, `dowod_urzadzenia` evidence, and how klyo_game_diagnostics surfaces it. Combined with the permission/Allow prerequisite and session lifecycle, an agent has everything needed to invoke it correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description meaningfully complements it by explaining the step grammar: steps run on one timeline of at most 3000 ms, each starts when the previous ends or at `at_ms` for parallelism, coordinates are fractions 0-1, up to 40 steps and 4 screenshots, and it lists the fields per step type. This composition semantics goes beyond the per-field schema text.

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 verb+resource ('Really play your game and see it: you send input steps, you get screenshots (image content) and the game state') and explicitly frames the mode as remote-on-owner's-device. It also distinguishes itself from siblings by tying its target to 'the same version klyo_game_files reads' and routing failures to klyo_game_diagnostics.

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 session lifecycle is spelled out clearly ('The first call opens the game, next calls continue it, `restart` reloads it, `close` ends the session'), and the error path names an alternative ('Errors from this session: klyo_game_diagnostics with `sesja` = `sesja.znacznik`'). It does not state explicit when-NOT-to-use conditions versus siblings like klyo_game_files, so it stops short of a 5.

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

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

Annotations already establish read-only, idempotent, closed-world behavior, but the description adds substantial context the annotations cannot: the returned standard is in Polish, covers screens, input, game loop, free asset catalogue, social layers, testing, release stages, and upload blockers. For a zero-parameter informational tool with no output schema, it thoroughly discloses what the agent will receive and the downstream test-gate requirement.

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?

It is front-loaded with 'GAME PRODUCTION CONTRACT: CALL THIS FIRST', which is good, but the body is a very dense run-on enumeration separated by semicolons, covering nearly every aspect of the standard. Much of the list is useful context, but the sheer density makes it harder to scan than it needs to be.

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 complex informational tool with no output schema and no parameters, the description explains what the standard contains, the language of the returned text, the testing gate, and why the user should not be asked routine setup questions. Nothing an agent needs in order to call it correctly or interpret the response appears to be missing.

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?

There are zero parameters, so the baseline is 4. The description confirms 'no parameters' and 'Read-only', which is consistent with the empty schema, but no additional parameter meaning is needed or supplied.

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?

It states a specific verb and resource ('Returns the studio quality standard') and explicitly positions itself as a prerequisite ('CALL THIS FIRST, before you design or write a single line of a game'). That distinguishes it from the many build/publish siblings such as klyo_game_scaffold and klyo_publish_game without opening their schemas.

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 explicit when-to-use instructions ('CALL THIS FIRST'), a concrete example ('when the user writes "make a battleship game"'), and a use-avoidance rule ('do not ask them about phones, leaderboards or sound: it is all here'). It also adds a completion condition ('Do not say "done" until klyo-test passes without critical errors'), leaving little to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description repeats 'Read-only' (redundant). However, it adds substantial behavioral context beyond annotations: the kit includes sound that resumes after backgrounding, safe areas, input handling unified, and the constraint 'You write ONLY the gameplay'. These are useful behavioral traits not in the annotations.

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 long but front-loaded with the purpose and workflow, then efficiently lists features in a colon-separated list. It includes examples at the end. Every sentence contributes to informing the agent about what the tool returns and when to use it, though it could be trimmed slightly without losing value.

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 tool has one optional parameter and no output schema, the description covers the return (two files and the API), the usage sequence, the parameter options, and example queries. It does not specify the exact format of the returned API, but that is likely in the files. The description is sufficient for an agent to decide when and how to call it.

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 schema has 100% coverage for the single parameter `rodzaj`, with detailed descriptions of each enum value. The description repeats these explanations and adds a reference game ('Reference game: Battleships'), but this is a minor addition. It does not compensate significantly beyond what the schema already provides.

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?

States a specific verb ('returns') and resource (two starter files and the kit API) with a clear header 'GAME SKELETON ON KLYO KIT'. It distinguishes itself by explicitly placing it in the workflow: 'call after klyo_game_requirements, before you write code', which separates it from siblings like klyo_game_requirements and klyo_game_sdk.

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?

Provides explicit when-to-use guidance: 'call after klyo_game_requirements, before you write code' and includes three example prompts that would trigger this tool. It does not explicitly list alternatives or when-not-to-use, but the sequence and examples give clear context for an agent.

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

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

Annotations already cover read-only, idempotent, non-destructive. The description adds that it 'needs no input' and describes the content scope. It doesn't contradict annotations and provides useful context about what to expect (a full description), though it doesn't detail return format or pagination – minor for an info tool.

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 longer than minimal, but every sentence earns its place: content enumeration, read-only note, usage ordering, consequences, and example queries. It is front-loaded with what the tool does and provides actionable guidance. Slight verbosity prevents a 5.

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 tool has no parameters and no output schema, the description is fully sufficient for an agent to decide when and how to call it. It covers purpose, prerequisites, and example triggers.

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 0 parameters and 100% schema coverage, the baseline is 4. The description explicitly states 'needs no input,' reinforcing the schema. No further parameter explanation is needed.

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 clearly states this tool provides the full SDK kit description, enumerating specific capabilities (leaderboard, saves, full screen, ad break, rewarded ad, clip recording). It distinguishes itself from siblings by explicitly ordering it after klyo_game_requirements and before game development.

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?

Gives explicit when-to-use guidance: 'CALL THIS RIGHT AFTER klyo_game_requirements, BEFORE YOU WRITE A GAME FOR klyo.' Also explains the negative consequences of skipping it (no leaderboard, no cross-device saves, ads will fail checks). This leaves no ambiguity about when to invoke this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description carries little safety burden. It adds the 'day by day' granularity and the revenue context, but it does not describe response format or behavior beyond what the schema's sprawdz_google parameter already explains.

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 core purpose is front-loaded in the first sentence, and the examples are compact and useful. There is no fluff or repetition of schema-level detail.

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 read-only, idempotent stats tool with fully described parameters and no output schema, this is nearly complete: it states the metrics, granularity, scope, and safety. It lacks only an explicit note on response shape or pagination, which is a minor gap.

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?

Schema description coverage is 100%, so all parameters are fully documented in the schema. The description's examples illustrate slug use but add no meaning beyond the schema.

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 clearly identifies what the tool returns: daily visits and plays for a specific game, with example queries showing intended use. It does not explicitly contrast this with siblings such as klyo_game_diagnostics, so some 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.

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

The examples like 'How many people played my game this week?' and the mention that ad revenue share is calculated from this data give clear usage context. It does not state explicit exclusions or alternatives, but the intended scenarios are easy to infer.

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

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false, and the description goes well beyond them: outputs are PROPOSALS requiring owner approval, failed languages return in `odrzucone`, resending is the fix path, saved addresses redirect 301. However it does not state permission/auth requirements or rate limits, and the `idempotentHint=false` implication (re-sending is expected/normal) is only implicitly handled via the retry loop.

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?

Dense but front-loaded: purpose first, then the two steps, then validation rules, then workflow and ordering. Every section carries operational information, though the PAGE ADDRESS and ORDER paragraphs make it longer than ideal for a two-parameter tool.

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 nested, multi-step tool with no output schema, the description covers what each call returns (`oryginal`, `do_tlumaczenia` with state, check rules, `odrzucone` with reasons), the approval lifecycle, the address stability rule, and ordering relative to release. An agent has everything needed to invoke and interpret it correctly.

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?

Schema coverage is 100% and the schema already documents slug, tlumaczenia structure and the adres format, so the baseline is 3. The description adds real meaning beyond the schema: the two-step sequence (call with only `slug` first), the requirement that ALL fields from `oryginal` be present, and the check rules applied per language. The overlap with the adres examples in the schema keeps it from a 5.

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?

States a specific verb+resource (translations of a game's texts into named klyo languages) and explicitly distinguishes itself from klyo_fix_game, which handles the developer's own texts. An agent can identify the tool and separate it from siblings without opening the schema.

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?

Gives explicit when/when-not guidance: the two-step call pattern (slug-only to fetch, then slug+tlumaczenia to save), the recommended order (translate before release while klyo_publish_game status is `oczekuje`), and the alternative for editing developer texts (klyo_fix_game). It even warns against a specific wrong behavior (don't tell the user translations are live).

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with a plain 'Read-only.' Beyond the annotations, it explains output content (e.g., 'state (published, or rejected with the reason)') and the tool's role as a prerequisite for other tools, adding useful behavioral context without needing to repeat safety metadata.

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 front-loaded with the primary action and output fields, followed by a crisp 'Read-only.' and the crucial first-step note. The three example questions are helpful but slightly redundant—they restate use cases already implied—yet they do not bloat the text excessively.

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 tool with no parameters, no output schema, and full annotation coverage, the description is complete: it tells the agent what the tool does, what results to expect (fields include slug, state, rejection reason), and when to invoke it. An agent can decide to call this first without needing additional details.

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?

There are zero parameters, so the empty schema already fully describes the input contract. The description adds no parameter details because none exist; per rubric, a zero-parameter tool receives a baseline of 4, as the description cannot add value beyond the schema.

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 states a specific action ('List this account's games') and a clear resource ('klyo games catalogue'), and enumerates the returned fields (name, slug, state, size, visits, plays). It differentiates from siblings by positioning itself as the tool to call FIRST to obtain the slug needed by other tools, so an agent can distinguish it without opening schemas.

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 explicit when-to-use guidance: 'Call this FIRST to learn the `slug` the other tools need.' This clearly places it before other catalogue tools, and the example questions illustrate typical use cases. It does not name dispreferred alternatives or conditions to avoid, hence the absence of explicit exclusions.

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

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

Annotations only say it is a non-read-only, open-world, non-destructive write, so the description carries real weight and delivers: 'IT DOES NOT PUBLISH', the game lands at g-<slug>.klyo.pl in `oczekuje` until the owner clicks Release, the package is downloaded and scanned (ads, malware, brands), and a white-screen follow-up path exists. It does not describe response shape or what happens on partial failure, so it stops short of a 5.

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 paragraph is dense and heavily capitalized but front-loads the action, then the crucial 'IT DOES NOT PUBLISH' correction, then routing rules and prerequisites, ending with concrete example utterances. For a 30-parameter tool with nested objects, nearly every sentence earns its place, though some restatement of schema limits could be trimmed.

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 30 parameters, nested questionnaires and reviews, no output schema, and high-stakes publishing, the description covers the outcome state, the address, the pre-call agreement requirement, the package review, the premium review gate, and the update-vs-create fork. Nothing an agent needs in order to call this correctly and set user expectations is missing.

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?

Schema description coverage is 100% and the schema text is extremely detailed (limits, refusal codes, questionnaire semantics), so the baseline is 3. The description adds a few cross-parameter rules (nowa_gra vs. update path, przeglad required for `gotowa`) but mostly restates constraints already in the schema and defers to it for limits.

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?

Opens with a specific verb and resource and scope: 'Prepare a browser game for release on games.klyo.pl', then enumerates exactly which fields the call assembles. It explicitly distinguishes itself from klyo_update_game and points to klyo_upload_package for the package, so an agent can tell it apart from every sibling without opening a schema.

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?

Gives explicit when-to-use and when-not-to-use: new game vs. new version of an existing game (use klyo_update_game with its slug), white screen → klyo_game_diagnostics, translations later via klyo_game_translate, owner must have accepted dev terms first. Alternatives and prerequisites are named, not implied.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the description doesn't need to restate those. It adds valuable behavioral context: the previous version's files are kept next to current ones, rolling back again swaps them, and the game's address/scores/stats do not change. It also discloses the refusal condition (brak_poprzedniej). This goes beyond the annotations and helps the agent predict side effects.

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 a single paragraph with a clear first sentence stating the action, followed by behavioral details and a usage scenario. It is front-loaded and every sentence adds information. It could be slightly more concise, but the length is justified by the need to explain the swap behavior and error condition.

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 single-parameter tool with no output schema, the description covers the action, side effects, error condition, and a recommended workflow. It doesn't describe the return value or output format, but since there is no output schema and the tool is a mutation, that is a minor gap. The description is complete enough for an agent to invoke it correctly.

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 schema already covers the single parameter (slug) with a description, so baseline is 3. The description adds context by explaining that slug is the game address in the catalogue and referencing klyo_my_games as the source, which helps the agent know where to get the value. This is a modest but real addition beyond the schema.

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 clearly states the tool rolls a game back to the previous version, identifies the resource (game slug), and distinguishes it from related operations like klyo_release_version. It also explains the mechanism (files kept, switch without uploading) and the error condition, making the purpose unambiguous.

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 explicitly says when to use it: when the owner reports a new version breaks the game. It also provides a workflow after rollback (fix locally, run klyo-test, klyo_update_game, klyo_release_version), which is strong usage guidance. It doesn't explicitly name alternatives, but the context and workflow make the appropriate use clear.

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

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

Beyond the minimal annotations, the description discloses rich behavioral effects: players immediately get the new version, mid-round players see an update bar, the previous version stays, the game page is rebuilt, followers are notified, and clip behavior changes per `zmiana` type. It also describes the review re-check before the swap. This is exactly the kind of context annotations cannot convey.

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 long but well-organized: core operation, then parameter effects, then gating conditions, then the review requirement, then examples. Some material repeats schema content, but for a complex release operation that reinforcement is useful rather than wasteful.

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?

Despite having no output schema, the description fully covers what the agent needs to call the tool correctly: the prerequisite (waiting version from klyo_update_game), the eligibility condition (owner confirmation), when evidence is required, and all user-visible side effects. Nothing critical for invocation is missing.

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 schema already provides detailed parameter descriptions and covers 100% of parameters, so the baseline is 3. The description adds value by explaining the default for omitted `zmiana`, the clip consequences for each change type, the `nowosc` feed behavior, and the condition under which `przeglad` is mandatory.

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 action on a specific resource: 'Release to players the version waiting after klyo_update_game (`slug`)'. It clearly identifies this as the update-release step and distinguishes it from other game lifecycle tools by pointing at the upstream update tool.

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 clear usage context: this tool is for releasing the waiting version after an update, and only when the owner has played the new version or deliberately waived that. It also states when a premium review is required. However, it does not explicitly tell the agent when not to use it or name alternatives such as klyo_publish_game or klyo_release_rollback.

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

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

Annotations already establish read-only/idempotent/no-destructive hints. The description adds value by specifying the payload contents (server version, key scope, account role, tool count, write permission) and the semantics of integration statuses (`ok`, `not_connected`, `auth_error`, `no_data`) plus embedded remediation guidance. It does not contradict annotations.

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 dense but arguably a little padded: 'Read-only' duplicates the annotation, and the three example questions are helpful but not strictly necessary. Core purpose and usage are front-loaded, and each remaining sentence contributes unique information.

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 zero-parameter read-only status tool with no output schema, the description fully covers what the agent will receive and when to call it. It includes the list of integrations, possible status values, and directs the agent to use it before critical decisions. Nothing essential is missing.

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 tool takes zero parameters, and the schema has no properties, so there is no parameter-level semantics to document. Baseline 4 for 0-param tools; the description appropriately focuses on output and usage instead.

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?

States a specific verb and resource: it reports the state of the klyo connection, enumerating server version, key scope, account role, tool count, write permission, and integration statuses with action items. The example questions make it unambiguous that this is a status/health-check tool, clearly distinct from the mutating sibling tools.

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?

Explicitly instructs to call it at the start of work and before relying on a possibly-unloaded report section, giving clear timing. It does not name alternatives or when-not conditions, but the sibling set makes the status role obvious and the examples reinforce the intended use cases.

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

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

Annotations establish that this is a mutating, destructive, non-read-only tool, and the description adds substantial side-effect detail beyond that: a published game does not change immediately, the new version replaces any version already waiting in the waiting room, an unpublished game gets the new files at once, and a human must record the clip. No contradiction with annotations exists.

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 long but appropriately dense: the main operation is front-loaded in the first sentence, and subsequent sentences each add critical workflow, side-effect, or exclusion information. The natural-language examples are compact and help an agent recognize user intent. There is no filler or repetition of the title.

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 complex mutation with no output schema, the description covers almost everything an agent needs: inputs, when changes become visible, the waiting-room replacement behavior, the zmiana response field, the release workflow, and the human-only clip recording. The main gap is that it never crisply states the one-of-upload_id/zip_url requirement or the behavior if both are supplied, which is a small but real omission.

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?

Schema description coverage is 100%, so the baseline is 3. The description does reinforce the file-vs-url source choice by mentioning klyo_upload_package and 'public zip_url', but it mostly restates the schema fields. It does not explicitly state that exactly one of upload_id or zip_url should be supplied or what should happen if both are provided, so it adds only moderate value beyond the schema.

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 concrete verb and resource: 'Upload a NEW VERSION of a game that is already on the account (`slug`)' and then names the two allowed package sources. It clearly differentiates this action from related siblings by stating the game 'keeps its address, name, description, scores and hearts; only the files change', which is not a tautology.

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 explicit when-to-use guidance: 'Do not create a second game to ship a fix: that splits players and records between two addresses.' It also explains the staged workflow, names klyo_release_version as the alternative release path, and notes when upload_id is preferred over zip_url. An agent gets clear decision rules rather than having to infer them.

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

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

Annotations are minimal (only four boolean hints), so the description carries the burden — and it delivers richly: the ticket is valid for one hour ONLY, opens no tool, must not be saved in project files, uploads land in a waiting room with nothing published, and the tool must be called again after manual upload. This far exceeds what the annotations disclose.

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 front-loaded with the core purpose and well-structured via a numbered three-part return list and a clear recipe. It is long (~230 words) and contains some parenthetical asides that could be tightened (e.g., 'it opens no tool; you do not have it in your configuration, which is why you get it here'), and the four examples slightly repeat stated use cases — but nearly every sentence earns its place.

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?

With no output schema, the description must explain return values, and it does comprehensively: all three returned items, the ticket's purpose and expiry, two execution paths (curl vs. owner upload), the re-call flow, and integration with sibling tools. The full lifecycle from disk file to publishable upload_id is covered with no critical gaps.

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 0 parameters, the baseline is 4 and there is nothing for the description to explain about schema fields. It does add useful invocation semantics by specifying where the returned ticket goes (Authorization: Bearer header) and what upload_id is for, which is context the empty schema cannot convey.

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 opening sentence states a specific verb and resource: "release a game from a file on disk, with no tunnel and without exposing an unreleased game publicly." The title reinforces the differentiator ('no public URL needed'), and the description names klyo_publish_game/klyo_update_game as the next step, making clear this is the disk-upload entry point rather than a publish/update tool.

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 explicitly routes the agent: pass the returned upload_id to klyo_publish_game or klyo_update_game instead of zip_url, and call the tool again after the owner uploads manually. The four examples map directly to trigger scenarios (disk file, owner uploaded in studio, avoid public exposure), leaving no ambiguity about when to choose this tool.

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