scene_set_player_count

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

Annotations already declare a non-read-only, destructive mutation, and the description adds genuinely useful behavior: a new map defaults to 1–8, playtests always run as one player regardless, and published levels feed lobby/matchmaking. However, it never explains what 'a copy of a save' means or what existing data the destructiveHint implies gets overwritten, which is the key risk for a write 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 operative constraint (min/max, up to 8) is front-loaded and every clause carries information; the UI path parenthetical is a useful locator. It runs long as a single dense sentence-chain and the trailing 'official samples' remark is the least essential part.

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 and four parameters, half of which are undocumented, plus an ambiguous 'copy of a save' target — for a destructive write tool this leaves real gaps. The behavioral notes about playtest and publishing are strong, but an agent still cannot confidently construct a call that specifies where the result is written.

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% schema coverage, the description does compensate well for min/max — the 'up to 8' ceiling, the {min, max} pairing, the min:1/max:1 single-player example, and the 1–8/1–4 official-sample conventions. But mapPath and outputName are never defined; 'in a copy of a save' is the only oblique hint at what those two string parameters target.

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 ('Set how many players the level takes') and even anchors it to the editor UI location (关卡设置 > 人数设置). An agent can tell this configures player-count bounds rather than other level settings, and the min/max semantics are 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?

Usage is only implied: the example values and the lobby/matchmaking note suggest when the setting matters, but the description never names an alternative such as scene_set_level_settings or scene_get_level_settings, nor states prerequisites like 'publish the level first'. An agent must infer routing from the sibling names alone.

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