Skip to main content
Glama

rename_bin_item

Rename a bin, clip, or sequence by providing its bin path and new name, so project items can be updated without manual navigation.

Instructions

Rename a bin, clip or sequence by its bin path.

Input Schema

NameRequiredDescriptionDefault
pathYes
projectNo
new_nameYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.7/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the agent knows this is a non-destructive, local mutation. The description adds only the target categories; it says nothing about whether the rename is persisted immediately, whether it is undoable, how name conflicts are handled, or what error states exist. For a mutation tool this is thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler. However, the brevity comes at the cost of substance rather than being a model of compressed information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Three parameters, zero schema descriptions, and a mutation operation — the definition should explain path syntax, project scoping, and rename side effects. An output schema exists so return values need not be described, but the input and behavioral picture is materially incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so all three parameters (path, project, new_name) are undocumented. The description hints that 'path' is a bin path but says nothing about the path format, the optional 'project' scoping parameter, or any naming constraints on 'new_name' — the schema's burden is not compensated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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

States a specific verb ('Rename') and enumerates the affected resources (bin, clip, sequence), plus the lookup key ('bin path'). That distinguishes it from siblings like move_bin_item and delete_bin_item, though the tool name's 'bin_item' wording slightly clashes with the broader 'bin, clip or sequence' scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No indication of when to prefer this over move_bin_item or delete_bin_item, no prerequisites (must the project be open? must the item exist?), and no note about what happens on name collisions. The agent is left to infer everything about invocation context.

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