Loading ToolBench
Personal music distribution tool — catalog management, SoundCloud/YouTube uploads, MCP integration
Music-distro exhibits widespread schema and description gaps that prevent confident LLM usage. Of 12 tools, 5 have no visible input schemas (distro_upload_soundcloud, distro_upload_youtube, distro_upload_all, distro_open_dashboard, distro_auth_soundcloud, distro_auth_youtube), and most descriptions lack actionable detail about parameters, side effects, and error recovery. Naming follows verb_noun convention which is good, but parameter descriptions are sparse or missing entirely. Tool compositions are reasonable (separate auth, upload, and catalog tools) but lack chaining IDs in responses, a tool returning track metadata should include the track UUID that downstream update or upload tools require. Error handling is absent, no recovery guidance, no retryability classification, no error examples. The server is STDIO-only, which is a hard transport limitation for protocol readiness.
Add an audio file to the catalog with metadata.
Initiate SoundCloud OAuth flow. Opens browser for authorization. Requires SoundCloud client credentials in the credentials vault.
Check which platforms are connected and authenticated.
Initiate YouTube OAuth flow. Opens browser for Google authorization. Requires client_secret.json from Google Cloud Console.
List all tracks in the catalog with metadata and release status across platforms.
Open the music distribution dashboard in the default browser.
Check the release status of all tracks across platforms.
5 tools have zero visible input schemas (distro_upload_soundcloud, distro_upload_youtube, distro_upload_all, distro_open_dashboard, distro_auth_soundcloud). Per hard scoring rule, schema score must be 0 when schemas are not visible in source. These tools cannot be safely invoked by LLMs without parameter guidance.
Most tool descriptions lack actionable detail about preconditions, side effects, and error recovery. E.g., distro_upload_soundcloud says 'Upload a track to SoundCloud' (26 chars) but does not explain: required auth state, what happens if auth is missing, expected response format, or retryability.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Scan ~/Desktop/AI-Music/ for new audio files not yet in the catalog. Auto-populates metadata from filenames and ffprobe.
Update metadata for an existing track in the catalog. Also writes ID3 tags to MP3 files.
Upload all pending tracks to configured platforms.
Upload a track to SoundCloud.
Upload a track to YouTube.
No error handling guidance. None of the tool descriptions explain what to do if a call fails. E.g., distro_auth_soundcloud might fail because credentials are missing, network is unreachable, or the OAuth code expired. An LLM receives a raw error with no recovery path. Pattern: recovery-guide.
Tool responses lack documented output schemas and chaining IDs. E.g., distro_scan_new likely returns a list of newly discovered tracks, but the description does not specify the response format or whether it includes track_id (needed for downstream distro_add_track calls). Unclear outputs break tool composition, agents cannot confidently chain tools when response structure is undocumented.
distro_add_track has optional 'file' parameter but it is marked required. The description says 'Audio file path or filename in AI-Music directory' but does not clarify: what exact format (absolute path, relative path, filename only)? If relative, relative to what? LLMs cannot disambiguate without explicit constraints.
No destructive operation guards. Tools like distro_upload_all are irreversible side effects (publishes audio to SoundCloud/YouTube) but descriptions give no warning and require no confirmation. Agents can be tricked via prompt injection into publishing content unintentionally. Pattern: confirmation-request.
Tool descriptions conflate prerequisites with functionality. E.g., distro_auth_youtube says 'Requires client_secret.json from Google Cloud Console' in the description. This is a deployment requirement, not a runtime precondition. Description should clarify: Is auth already set up? Will this tool set it up? Does it fail gracefully if credentials are missing? LLMs need to know when to call this tool and what happens if conditions are not met.