traktor-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| statusA | Where the Traktor collection and the two lanes stand: how many entries, how many files are in the lanes, and how many of each thing a run would do. Reads the whole collection and both lanes, writes nothing. |
| planA | What a run would change, writing nothing: every entry to repoint onto the file that replaced it, every lane file to add, and every entry whose file is gone — either a duplicate the collection holds elsewhere, or a file that is not there and was not replaced. |
| purgeA | Take out every entry in the collection whose file is gone — residue, since a collection is an index of files that exist. A playlist reference to a removed entry is moved to the entry that keeps the track, or dropped when nothing does; history, cues and play counts go with the entry and are reported. Dry run unless apply is true. Refuses while Traktor is running, and takes one backup beside the collection before it writes. |
| applyA | Write the plan into the collection: one backup beside it, then one edit that leaves every entry nobody is repointing byte for byte as Traktor wrote it. Refuses while Traktor is running. Returns what was written and what to do in the app afterwards. |
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 4 tools
status and plan are distinct read-only views, but purge and apply both mutate the collection with backups and Traktor-running guards, and plan already reports removals that purge handles. The boundaries are understandable from descriptions but not fully crisp.
All names are single lowercase words, but the set mixes noun-like status/plan with verb-like purge/apply, so there is no predictable action pattern. It is readable but not systematic.
Four tools map cleanly to inspect, preview, clean, and commit operations for a narrow collection-maintenance utility. No tool feels extraneous for the stated scope.
The surface covers the main lifecycle: status, plan, purge, and apply with backups. Minor gaps include no explicit post-apply verification or backup/restore management, but core workflows are covered.