Loading ToolBench
MCP server for managing and analyzing Ableton Live projects. Extracts BPM, track counts, plugin inventories, and project metadata from .als files.
The server defines 8 tools with consistent structure, but shows significant gaps in schema completeness and parameter documentation. All tools have descriptions (range: 180 - 520 chars, within the 10 - 1024 baseline), and naming follows verb_noun convention (scan_, analyze_, find_). However, parameter schemas lack type definitions for array items, enum constraints are absent where applicable, and no output schemas are documented. Error handling is minimal, most tools return generic error dicts without recovery guidance. The tool names are clear and action-focused, which is a strong point. Overall, this is solid groundwork that falls short of production grade due to incomplete schemas and missing validation/recovery patterns.
Extract and compare master track device chains across multiple projects. Returns: JSON grouped by unique master chains, showing which projects use each chain. Use cases: - "Do I reuse the same mastering chain across projects?" - Finding projects with similar mastering setups - Identifying your mastering patterns/templates Example: Groups projects using "EQ8 → Glue Compressor → Limiter" together.
Deep analysis of specific Ableton Live projects. Extracts comprehensive metadata from .als files. Returns: JSON with BPM, track details, plugins, master chain, arrangement structure, completion indicators, and more. What it analyzes: - Basic: BPM, track counts (audio/MIDI/frozen) - Structure: Arrangement length, scenes, markers, automation lanes - Plugins: All third-party plugins, CPU-heavy plugin count - Master chain: All devices on master track - Tracks: First 10 tracks with names, types, devices, frozen status - Completion: Heuristic for whether project is likely finished - Content hashes: For duplicate detection Performance: Each project requires XML parsing (gzip decompression + parse). Use scan_projects first to get paths. Best practice: Analyze 5-10 projects at a time, not all at once.
Find duplicate Ableton projects based on content similarity, not just filename. Analyzes: Track structure, device chains, MIDI patterns, BPM, track counts, master chains. Returns: JSON with pairs of similar projects, similarity scores, and comparison details. Similarity factors: - Content hash (track names + device chains): 40% - Track count match: 15% - BPM match: 10% - Master chain match: 20% - MIDI pattern hash: 15% Use cases: - "Do I have multiple versions of the same project?" - Cleaning up before backup - Finding alternate versions (e.g., "Project v1", "Project v2", "Project FINAL") Performance: Analyzes ALL projects in directory (up to 100), then compares pairs. Can be slow for large collections.
No output schemas documented for any tool. LLMs cannot predict response structure or plan downstream calls. The code comments mention return structure (e.g., 'Returns: JSON with project names, sizes...') but no formal schema is provided.
Array parameter 'project_paths' (analyze_projects, analyze_master_chains) lacks 'items' type definition. Schema shows {"type":"array","items":{"type":"string"}} but no description for what constitutes a valid path or constraint on array length. LLMs may pass invalid or huge arrays.
Numeric parameter 'threshold' (find_duplicates) and 'limit' (find_recent) lack min/max constraints in schema. 'threshold' accepts 0-100 per description but schema has no bounds; 'limit' defaults to 10 but schema shows no constraint preventing absurd values (e.g., limit=999999).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Classify projects as 'likely finished' vs 'sketches' using heuristics. Classification criteria (needs 3+ to be 'finished'): - Has 3+ arrangement markers (like DROP, VERSE, OUTRO) - Has 2+ devices on master track (mastering chain) - Arrangement is 64+ bars long - Has 5+ scenes in session view Returns: JSON with two lists: finished projects and sketches, with completion indicators. Use cases: - "Which projects are ready to export/release?" - Separating ideas from complete tracks - Finding abandoned projects vs works-in-progress Note: This is a heuristic, not perfect. Your workflow may differ.
Scan projects and list all third-party plugins used. Useful for checking plugin availability. Returns: JSON with all unique plugins found across projects, and which projects use each plugin. Use cases: - "What plugins do I need to open these projects?" - Checking before moving projects to a new computer - Finding projects that use a specific plugin Note: Does NOT actually verify if plugins are installed (no access to system VST folders). It lists what's in the projects.
Scan projects for missing audio samples/files. Returns: JSON with projects that have missing samples, showing which samples are missing and the total count. Use cases: - "Do I have missing samples in my projects?" - Checking project integrity before sharing/archiving - Finding broken file references after moving projects - Identifying which samples need to be collected Note: Only checks if the file path exists, doesn't verify file integrity.
Find the most recently modified Ableton projects in a directory, sorted by modification time. Returns: JSON with the N most recent projects, including paths, names, folders, modification dates, and sizes. Use cases: - "What have I been working on lately?" - Quick access to active projects - Finding projects modified in the last week/month Comparison with scan_projects: - scan_projects: Returns ALL projects (up to limit), unsorted - find_recent: Returns ONLY the N most recent, sorted by time This is faster than scan + sort if you only need recent projects.
Scan a directory for Ableton Live .als project files and return basic metadata. Returns: JSON with project names, sizes, modification dates, and folder locations. Use cases: - Initial discovery: "What projects do I have in this folder?" - Quick overview without deep analysis - Getting file paths for use with analyze_projects Safety limits: - Scans max 100 files (configurable) - Skips files over 50MB - Only goes 3 folders deep - Excludes heavy folders (Backup, Samples, Library) Use this FIRST to discover projects, then use analyze_projects for detailed info.
Error handling is generic and non-recoverable. All tools return {"error": "...", "projects": [], ...} without guidance on next steps. Per pattern:recovery-guide, errors should suggest alternatives (e.g., 'Directory not found, try expanding the path with os.path.expanduser' or 'File not found, available projects: [...]').
No pagination or result limits for discovery tools. 'find_missing_plugins' and 'find_duplicates' scan up to 100 projects and compare all pairs, but return all results without limit. A collection of 1000 projects could return 500K+ duplicate pairs, exhausting context and tokens.
No input validation or constraints on 'directory' parameter across all tools. Missing checks for path traversal (e.g., '../../../etc/passwd'), symbolic link loops, or non-existent parent paths. Per pattern:tool-gateway, all agent input is untrusted.
No idempotency or retry semantics declared. Tools that perform analysis (analyze_projects, find_duplicates) may be retried on timeout, but no idempotency guarantee is given. Per pattern:idempotent-operation, agents need to know whether retrying is safe.
Parameter descriptions reference internal limits (MAX_FILES_TO_SCAN, MAX_FILE_SIZE_MB, SCAN_DEPTH) but do not make constraints explicit in schema or parameter descriptions. LLMs cannot predict when a scan will hit the limit without reading implementation details.
Tool descriptions mix WHAT, WHEN, and HOW at different abstraction levels, violating pattern:tool-description guidance. E.g., analyze_projects includes 'Each project requires XML parsing (gzip decompression + parse)', implementation detail; and 'Use scan_projects first to get paths', ordering hint that should be in tool selection logic, not description.