talkback-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WS_PORT | No | WebSocket port for bridge connection | 8765 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_session_contextA | Returns a snapshot of the current Ableton session: all tracks (names, volumes, panning, mutes, sends, device chains), return tracks, master track, and routing. Call once at the start of a conversation to orient yourself. No need to call again unless the user says the session has changed. |
| get_track_detailsA | Returns full detail for a specific track including all devices, every parameter in human-readable units, and per-device observations. |
| get_spectral_snapshotA | Captures ~2 seconds of live audio from the master bus and returns peak/RMS levels across frequency bands. Transport MUST be playing — coordinate with the user on which section to analyze (e.g., 'play the chorus'). This is a point-in-time microscope, not a full-song analyzer. Use as a secondary check to verify what device parameter analysis suggests, or to detect issues invisible in the device chain (masking, phase, resonances). For most frequency questions, reading EQ and filter parameters via get_track_details is more informative. |
| get_plugin_libraryA | Returns all audio plugins (AU, VST3) installed on this system. Use to know what tools the producer has available. |
| analyze_mixA | Runs rule-based heuristic analysis for potential mix issues: frequency buildup, dynamics problems, routing inefficiencies, headroom. Only call when the user explicitly asks for mix feedback or describes a specific problem — do NOT call proactively. Findings are suggestions to consider, not problems to fix. Mix quality is subjective — frame results in context of what the user is trying to achieve. A technically 'imperfect' setting may be an intentional artistic choice. |
| set_device_parameterA | Sets a device parameter to a new value. Pass values in human-readable units (dB, ms, Hz, ratio, percent). NEVER call without explicit user approval. Present the planned change with current → proposed values first, wait for a clear 'yes', then execute. If the user modifies the plan, re-present and re-confirm before executing. |
| toggle_device_bypassA | Enables or bypasses a device on a track. Useful for A/B comparison. Always confirm with the user before toggling. |
| create_group_trackA | Creates a new group track containing the specified tracks. Always confirm with the producer first. |
| set_track_routingB | Changes a track's output routing. Always confirm with the producer first. |
| get_bridge_healthA | Returns performance metrics from the M4L bridge device: poll execution time (avg/max), WebSocket message size, LiveAPI cache size, and track count. Use to diagnose performance issues or confirm the device is running efficiently. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool targets a distinct resource or action: session snapshot, track details, spectral capture, plugin library, mix analysis, device parameter setting, bypass toggling, group creation, routing changes, and health monitoring. No two tools have overlapping purposes; the descriptions clearly differentiate them.
All tool names follow a consistent verb_noun pattern: get_* for read-only operations, set_* for value changes, toggle_* for binary state, create_* for new objects, and analyze_* for analysis. The naming is uniform and predictable.
With 10 tools, the server is well-scoped for its purpose of Ableton session mixing assistance. Each tool serves a clear function, and the count is neither sparse nor overwhelming.
The tool set covers session reading, detailed track inspection, spectral analysis, plugin discovery, mix analysis, device parameter control, bypass toggling, group track creation, routing changes, and health monitoring. Minor gaps exist for track-level volume/pan/mute/solo controls, but the core mixing workflow is well-covered.