Skip to main content
Glama

Create DJ-style decks

create_decks

Build a DJ-style VJ mixer with 2-8 decks, per-deck gain and FX sends, a crossfader, and a hard-cut transition bus for smooth mixing.

Instructions

Build a DJ-style VJ mixer. Without decks[], it preserves the legacy A/B Cross TOP mixer with GainA/GainB controls. With decks[], it builds a 2-8 deck mixer: every deck pulls a source TOP (or a test source) through gain and FX-send Level TOPs, decks 3+ blend into a running Cross TOP chain, a Switch TOP provides hard transition cuts, a final Cross TOP blends program vs cut, and an additive FX-send bus returns per-deck sends into the master. Output is a Null ready for post-processing or setup_output.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deck_aNoAbsolute path of the source TOP for deck A (pulled in via a Select TOP, so it can live in another container). If omitted, a built-in test source (Noise TOP) is created so the mixer builds standalone.
deck_bNoAbsolute path of the source TOP for deck B (pulled in via a Select TOP). If omitted, a built-in test source (Ramp TOP) is created so the mixer builds standalone.
crossfadeNoMaster crossfader position: 0 = full deck A, 1 = full deck B, 0.5 = even blend.
decksNoOptional N-channel deck list. When supplied, create_decks builds a 2-8 deck mixer with per-deck gain, FX sends, a running blend chain, and a hard-cut switch bus.
cut_deckNoZero-based deck index selected by the hard transition-cut bus in N-channel mode.
cut_mixNoBlend between the continuous program mix and the hard transition-cut bus: 0 = program mix, 1 = cut bus.
expose_controlsNoExpose live 'Crossfader' + per-deck 'GainA'/'GainB' knobs on the container so the mix is playable on arrival.
parent_pathNoParent COMP the mixer container is built inside (default '/project1')./project1
Behavior4/5

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

Annotations indicate readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds significant behavioral context: it creates a mixer with specific internal nodes (Select TOP, Cross TOP, Switch TOP, etc.) and outputs a Null. It does not contradict annotations. The description enriches understanding 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?

The description is a single paragraph that is detailed but efficient. It front-loads the purpose and then explains modes. While it could be slightly more structured (e.g., separated paragraphs for modes), it is concise and every sentence adds value. Score 4 for good but not perfect conciseness.

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

Completeness5/5

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

Given 8 parameters, no output schema, and annotations, the description covers both modes, internal architecture, and output behavior ('Output is a Null ready for post-processing or setup_output'). It fully explains the tool's behavior and results, making it contextually complete.

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

Parameters3/5

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

Schema coverage is 100% with detailed parameter descriptions. The description adds minimal new parameter semantics beyond summarizing the overall workflow. It helps contextualize parameters like decks and crossfade but does not provide extra schema-level details. Baseline 3 is appropriate.

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?

The description clearly states it builds a DJ-style VJ mixer, distinguishing between legacy A/B cross mixer and N-deck mixer with 2-8 decks. The verb 'Build' and resource 'DJ-style VJ mixer' are specific, and it differentiates from sibling create tools by specifying the internal architecture and mode switching.

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?

The description explicitly explains two usage modes: without decks[] (legacy A/B) and with decks[] (N-deck mixer). It implies when to use each mode but does not explicitly state when not to use or provide alternatives. Given the sibling tools are numerous, a clearer exclusion would improve this score.

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