set_scene_name

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

There are no annotations, so the description must bear the full burden of behavioral disclosure. It only says 'Rename' which implies a mutation but does not explain what happens if the scene_name is not found, whether renaming affects references to the scene, or any error conditions. This is a significant gap for a mutating operation with no structured 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 extremely concise, with one purpose sentence and two Arg lines. It avoids unnecessary fluff and is easy to parse. The only minor issue is that the Arg lines repeat information already visible in the input schema, but they do add a slight semantic value, so the structure is acceptable for its brevity.

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 simple rename tool, the description is minimally acceptable but not complete. It lacks discussion of failure modes, permissions, or uniqueness. Since there is no output schema, the description could at least mention that the operation either succeeds or throws an error. Given the simplicity of the operation, this is a moderate gap rather than a severe one.

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 0%, so the description must compensate. It adds semantic meaning by labeling scene_name as 'Current name of the scene' and new_scene_name as 'New name,' which clarifies the role of each parameter beyond the schema property titles. However, it could provide more detail such as uniqueness constraints or case sensitivity, so it only partially compensates.

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 'Rename a scene' with a specific verb and resource. It is distinguishable from sibling tools like set_input_name or set_source_filter_name by explicitly targeting scenes. Even without a title, the one-line description fully conveys the tool's purpose.

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?

No guidance is provided about when to use this tool versus alternatives. It does not mention prerequisites (e.g., the scene must exist) or relationships with other scene operations like create_scene, remove_scene, or set_current_program_scene. The description is only a bare statement of intent, leaving the agent without context for selecting this tool among many scene-related siblings.

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