Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This Rust-based music storage MCP server has significant quality gaps despite handling a complex domain. Of 25 tools, only 2 have been visibly scrutinized in the provided source code (apply_naming_scheme and apply_plan). The remaining 23 tools are listed but their implementations are not shown, meaning parameter schemas, descriptions, and error handling cannot be verified. The two documented tools show good intentions (comprehensive descriptions for apply_plan, clear risk categorization) but lack complete input schema visibility in the excerpt. Critical issues: (1) 92% of tools lack visible schema definitions in the code provided, making compliance unmeasurable. (2) Many tool names are ambiguous or inconsistent (e.g., 'fs_*' prefix lacks clarity on scope; 'mb_*' tools lack descriptions in the listing). (3) No visible parameter-level descriptions for most tools. (4) Error handling and output schemas not documented in the source excerpt. (5) Composition concerns: fs_list_dir, fs_mkdir, fs_move, fs_delete, fs_scan_audio all operate on the filesystem, unclear how they relate or compose. The server appears to follow good Rust patterns (trait-based abstraction via MbBlockingTool, caching, cancellation via tokio), but the MCP tool interface itself lacks the rigor required for LLM agents to confidently select and invoke tools.
Tools (25)
apply_naming_schemeread onlysource verified85/100
Render a relative path from a template and a metadata map. Placeholders: {name}, {name|fallback}, {name:0Nd} (zero-padded integer), or combined. Each substituted value is sanitised (OS-unsafe characters replaced with '-') by default. Pure function: no filesystem I/O. Refuses absolute paths and '..' components.
apply_planwritesource verified80/100
Execute an ordered list of operations (mkdir, move, write_metadata, embed_cover) in a single MCP call. Each entry carries the same shape as its singleton tool, plus an 'op' discriminator. With dry_run=true the plan validates every op without touching state. With stop_on_error=true the loop halts at the first failure; already-committed ops are NOT rolled back (filesystem rollback cannot be guaranteed safely). Hard-capped at 1000 operations per call.
Input schemas not visible in source code for 23 tools. Cannot verify parameter types, descriptions, or validation. Source only shows Tool registration via trait-based abstraction (MbBlockingTool) with generic schema_for_type derivation, but concrete Params types are not shown for most tools.
find_duplicates
Recommendations
For the 23 undocumented tools: add descriptions following the rubric pattern (WHAT does it do, WHEN to call it, WHAT it returns). Target 100-250 characters per description. Example for fs_scan_audio: 'Recursively scan a directory for audio files, extract metadata (format, bitrate, duration) from each file. Use this to audit a music library before applying naming schemes. Returns array of {path, format, duration_seconds, bitrate_kbps}.'
Expose concrete Params struct definitions for each tool in the source, alongside JsonSchema derives. This enables verification that parameter types and descriptions meet the rubric. Currently only apply_naming_scheme and apply_plan Params are visible in the excerpt; the remaining 23 are inferred.
Add parameter-level descriptions to every field. Example for apply_naming_scheme template param: 'Template string using placeholders {name}, {name|fallback}, {name:0Nd} (N-digit zero-padded integer), or combinations. Sanitized by default (OS-unsafe chars → dash). Must be relative (no leading /, no ..).'
For destructive tools (fs_delete, fs_move with overwrite), implement a confirm_before_execute pattern: add a 'dry_run' boolean parameter that validates without touching state, and require explicit 'confirm=true' for irreversible operations. Document in descriptions: 'Pass dry_run=true to validate paths without deleting. Pass confirm=true only after confirmation.'
For filesystem operations (fs_*), add a composition guide in apply_plan or tool documentation explaining the recommended call order (scan → mkdir → write metadata → move → verify). This reduces agent decision-making overhead.
Spec posture evidence
Inferred effective spec: 2025-06-18+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
apply_plan description uses technical jargon ('dry_run', 'stop_on_error', 'rollback') without explaining when an agent should use this tool vs. individual operations. Missing: WHEN to call this (composition rationale).
Filesystem tools (fs_*) lack clear separation of concerns. fs_list_dir, fs_mkdir, fs_move, fs_delete, fs_scan_audio all operate on files/directories, unclear which to call for common tasks. No composition guidance; agents must reason about ordering (mkdir before move, delete before write).
MusicBrainz search tools (mb_*_search) use generic 'search' naming without explaining what data source they query (MusicBrainz), what they return, or when to prefer one search type over another (artist vs. recording vs. release). Names do not clarify scope.
No visible error handling documentation. apply_plan mentions 'dry_run' for validation and 'stop_on_error' flag, but no guidance on what errors agents should expect or how to recover. Pattern recovery-guide not evidenced.
Output schemas not documented in provided source. apply_plan describes inputs but response structure is not shown. Cannot verify whether LLM can extract IDs, field mappings, or next steps from tool responses.
Destructive operation (fs_delete) has Risk=DESTRUCTIVE but no visible dry-run or confirmation mechanism in the definition. Pattern confirmation-request not evidenced.
Manifest tools (manifest_list, manifest_read, manifest_write) use domain-specific term 'manifest' without explaining what a manifest is, what format it takes, or when agents should use them. Not self-documenting.
manifest_listmanifest_readmanifest_write
For MusicBrainz search tools, enhance descriptions to clarify what each searches: 'Search the MusicBrainz artist database for recordings, releases, and metadata matching a query. Use this to find discography or verify artist identity before embed_cover or write_metadata.' Make the source and use case explicit.
Add output schema documentation for each tool. Examples: apply_plan should document {success: bool, operations_executed: int, skipped: int, stopped_early: bool, per_op_results: [{op_index: int, success: bool, error?: string}]}. embed_cover should document {file_path: string, cover_embedded: bool, new_file_size_bytes: int}.
For apply_plan and batch tools, clarify partial failure semantics. Document: 'If 5 of 100 operations fail and stop_on_error=true, returns stopped_early=true, skipped=95, and a per-op_results array so the agent knows which operations succeeded. Agents can retry skipped operations separately.'
Add error recovery guidance to each tool. Example: 'If fs_delete returns 'Permission denied', the agent should ask the user for elevated permissions or suggest a different directory. If 'Path not found', suggest fs_list_dir to verify the path exists.'