ide-save-scene

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

No annotations exist, so description bears full burden. It mentions code generation and prefab propagation, but omits details like whether the operation is safe to redo, what gets overwritten, or any side effects. Lacks thorough disclosure for a mutation operation.

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 sentences with some redundancy (e.g., 'Save the the editor' and later 'When the scene is saved'). Could be more concise and front-loaded. Adequate but not optimally structured.

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 simple schema and no output schema, the description covers purpose and usage scenarios. However, lacks behavioral details (e.g., persistence guarantees, error cases), leaving it slightly incomplete for a save operation.

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 has 100% coverage for the single parameter, but description adds value by clarifying that sceneId is a unique identifier, not the name, and explains how to obtain it. This reduces ambiguity beyond the schema alone.

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 saves a scene and triggers code generation, distinguishing it from other scene manipulation tools. The phrasing 'Save the the editor' is slightly awkward but the core action is clear.

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 guidance on when to save: when working simultaneously in scene and code files, and after modifying prefab scenes to propagate changes. Does not list when not to use, but context is strong.

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