Skip to main content
Glama
sandraschi

Mixx-DJ-MCP

by sandraschi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

mixx_deck

Control Mixxx deck playback, transport, loops, cues, and sync via natural language. Manage track loading, rate adjustment, hotcues, and video output.

Instructions

Comprehensive deck control for Mixxx.

PORTMANTEAU PATTERN: Consolidates all deck playback and transport controls.

SUPPORTED OPERATIONS:

  • play_pause: Toggle play/pause on deck

  • stop: Stop playback completely

  • load: Load a track to deck (requires track_path)

  • cue_set: Set cue point at current position

  • cue_play: Play from cue point

  • loop_activate: Toggle loop on/off (requires enable)

  • loop_beat: Set loop of specified beats (requires beats)

  • beatloop: Same as loop_beat

  • rate_set: Set playback rate/BPM adjustment (requires value, -1.0 to 1.0)

  • rate_temp: Temporary pitch bend (requires value, seconds)

  • sync_enable: Toggle sync lock (requires enable)

  • sync_leader: Set deck as sync leader (requires enable)

  • seek: Seek to position in seconds (requires value)

  • scratch: Enable/disable scratch mode (requires enable)

  • hotcue_activate: Activate hotcue by number (requires hotcue)

  • quantize: Toggle quantize mode (requires enable)

  • keylock: Toggle keylock (requires enable)

  • video_enable: Toggle video playback for deck (requires enable)

  • video_fullscreen: Toggle video fullscreen output (requires enable)

Returns: Dict with operation result

Examples: mixx_deck("play_pause", deck=1) mixx_deck("load", deck=1, track_path="C:/Music/track.mp3") mixx_deck("rate_set", deck=1, value=0.05) mixx_deck("loop_beat", deck=1, beats=8) mixx_deck("sync_enable", deck=2, enable=True) mixx_deck("hotcue_activate", deck=1, hotcue=3)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deckNo
beatsNo
valueNo
enableNo
hotcueNo
operationYes
track_pathNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4/5.0
Behavior3/5

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

No annotations provided, so the description carries the full burden. It discloses parameter requirements per operation (e.g., load requires track_path, loop_activate requires enable) and a value range for rate_set (-1.0 to 1.0), which adds useful behavioral context. However, it omits side effects (e.g., whether load replaces the current track), permissions, and reversibility of mutations.

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

Conciseness5/5

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

Well-structured with front-loaded purpose, a portmanteau note, a complete operation list, a return note, and examples. The operation list is long but necessary given 0% schema coverage; every section earns its place.

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?

Given a complex 19-operation tool with no annotations and 0% schema coverage, the description covers operations and required params thoroughly, and an output schema covers returns. Gaps remain in deck parameter semantics and behavioral safety, but overall it is nearly complete.

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 description coverage is 0%, so the description bears the burden. It compensates well by listing required parameters for each operation, but misses describing the deck parameter (default 1, likely deck number) and leaves value semantics ambiguous for rate_temp ('requires value, seconds').

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?

States a specific verb and resource: 'Comprehensive deck control for Mixxx' and 'Consolidates all deck playback and transport controls.' Enumerates 19 supported operations, making it immediately clear what the tool does and distinguishing it from siblings like mixx_mixer and mixx_effects.

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

Usage Guidelines3/5

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

Does not explicitly state when to use this tool versus alternatives like mixx_mixer or show_deck_status_card. The operation list implies it is the canonical deck-control tool, but no when-not-to-use, prerequisites, or alternative routing is given.

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

Deploy Server

Other Tools