MCP server + workers for audio download/convert/tag from SoundCloud, YouTube, and Yandex Music with FastAPI backend
Three tools with reasonable naming (verb-first) and documented descriptions, but schemas lack critical parameter constraints, output documentation is missing, and error handling guidance is minimal. Tool names are clear but descriptions are short and lack WHEN/WHY context for LLM selection. Parameters have type definitions but are missing enums for constrained fields (format, quality). No documented output schemas visible in source. The server supports resources and logging, showing some production awareness, but tooling patterns are incompletely realized.
Enqueue a download job for audio media from a given URL with optional format/quality settings
Get the current status of a download job including metadata and artifacts
Probe a media URL to detect provider and retrieve metadata (title, artist, duration, artwork)
Parameter 'format' in enqueue_download accepts free-form strings (mp3/flac/aac/opus) but lacks enum constraint in schema. LLMs may hallucinate unsupported formats.
Parameter 'quality' has example values in description ('v0/v2/320') but no enum schema. Quality values are format-dependent (mp3 vs opus vs aac), creating hidden parameter relationships that are undocumented.
Tool descriptions (50-65 chars each) are below the baseline average of 194 chars. Lack WHEN to use context, LLM cannot distinguish between probe_url and get_job_status without experimentation.
No documented output schemas for any tool. LLMs do not know what fields to expect (e.g., does probe_url return 'artwork_url' or 'cover'?). Breaks chaining and forces extra discovery calls.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
No error handling guidance in tool descriptions. If a URL is unsupported or a download fails, the LLM has no recovery path. Missing recovery-guide pattern.
enqueue_download performs a destructive operation (downloads and stores media) but lacks a dry-run or confirmation mechanism. No confirmation-request pattern implemented.
probe_url description mentions 'YouTube, SoundCloud, or Yandex Music' but does not state what happens if an unsupported provider is passed. Incomplete constraint documentation.
get_job_status accepts 'job_id' but does not document what fields are returned when a job is pending, succeeded, or failed. No per-state output documentation.