Skip to main content
Glama

Create look bank

create_look_bank

Store and recall named parameter snapshots (looks) for a control COMP. Use a built-in A↔B morph knob to blend between two looks with optional beat-quantized crossfades.

Instructions

A playable snapshot row: store N named 'looks' (snapshots of a control COMP's numeric/toggle/menu parameters) in a visible, editable Table DAT, with one momentary recall button per slot (snap or crossfade) plus a master A↔B morph knob that blends continuously between two chosen looks. Reuses manage_cue's morph engine (so a recall behaves exactly like a cue morph, with optional beat/bar quantize) and mirrors slots into the COMP's cues so they interoperate with manage_cue / create_control_surface. Pulses and strings are always skipped at capture. Build cues/params with create_control_panel first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNobuild: create the look-bank container (Table DAT + A↔B morph knob + recall button row) on a control COMP. store: snapshot the COMP's current numeric look into a named slot. recall: jump or crossfade to a slot. set_ab: assign which two slots the A↔B knob blends, and optionally set the knob. list / delete slots.build
comp_pathNoControl COMP whose custom-parameter values the looks capture (a control-panel container, e.g. from create_control_panel). The look-bank widgets are built inside it; recall drives this COMP's params./project1
nameNoName of the look-bank panel container built inside comp_path.look_bank
slotNoSlot name (required for store / recall / delete).
morph_secondsNo(recall) 0 = snap instantly; >0 = crossfade to the slot over this many seconds (eased), via the cue morph engine.
quantizeNo(recall) Defer the snap/crossfade to the next musical boundary (project tempo), so look changes land on the downbeat. Mirrors manage_cue.off
slot_aNo(set_ab) Slot the A↔B knob reads at value 0.
slot_bNo(set_ab) Slot the A↔B knob reads at value 1.
abNo(set_ab) Optionally set the A↔B knob position now (0 = slot A, 1 = slot B, 0.5 = halfway). Omit to just (re)assign the slots.
includeNo(store) Restrict the snapshot to these custom-parameter names. Omit to capture every numeric/toggle/menu parameter (pulses and strings are always skipped).
Behavior4/5

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

Discloses creation of Table DAT, buttons, morph knob, and that pulses/strings are skipped. Reuses manage_cue engine and mirrors slots into cues, providing behavioral context beyond annotations.

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?

Description is dense but each sentence adds value. Front-loaded with core purpose, but could be slightly more streamlined. Still well-structured.

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

Completeness4/5

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

Covers the tool's purpose, components, behavior, dependencies, and interoperability sufficiently. Without output schema, return behavior is not detailed, but overall context is clear.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. Description adds meaning by explaining how parameters like slot, morph_seconds, and quantize fit into recall actions, and ties parameters to overall functionality.

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

Purpose5/5

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

Clearly states it creates a playable snapshot row for storing and recalling looks of a control COMP. Distinguishes from siblings by mentioning reuse of manage_cue's morph engine and interoperability with manage_cue/create_control_surface.

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

Usage Guidelines4/5

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

Provides context: prerequisites (build cues/params with create_control_panel first), and mentions what is always skipped. Does not explicitly list exclusions or alternatives but gives clear usage context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Pantani/tdmcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server