cg_sdk_session

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

With no annotations, the description carries the full burden. It does disclose meaningful behavior: a play -> idle -> hide-tab lifecycle, an emulated ad with configurable outcome, and the categories monitored (autosave, save on hide, sound during ads, console errors). It omits key operational traits such as runtime (the default 35s idle, up to 300), whether it launches a browser, and whether/where it writes a report.

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 first sentence front-loads the action and lifecycle, which is the most important information. The second sentence is a comma-separated heap of check names, but each item is substantive and tells the agent what the session will cover, so the density earns its place rather than padding.

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 harness with no annotations and no output schema, the description explains the session flow and the verdict categories but never says what the return value looks like, where results are written, or how long a run takes. It is adequate to recognize the tool but leaves an agent unable to predict the call's cost or result shape.

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 88%, so the schema already documents path, init, query, steps, dialog, engine, adOutcome and idleSeconds in detail (including the autosave >= 32 hint). 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 states a concrete verb and resource: play the build in an emulated CrazyGames frame with an SDK emulator, then idle and hide the tab, producing verdicts. The verdict list further pins down the scope (gameplay pairs, autosave, rewarded cooldown, console errors). It is clear, but it never names cg_build_check or cg_frame_audit, so the agent must infer the split from the sibling names alone.

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?

Usage is implied rather than stated: the enumeration of SDK/behavioral verdicts signals this is the tool for behavioral SDK verification during a simulated session. There is no explicit when-to-use versus cg_build_check or cg_frame_audit, and no stated prerequisites or exclusions.

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