Loading ToolBench
MCP server for the Distill file renaming application. Provides tools to rename files using AI analysis, manage renaming rules, configure AI providers, and monitor folders for automatic renaming.
This server has moderate structural quality but significant definition gaps. All 9 tools are explicitly registered with names, input schemas, and descriptions visible in Sources/DistillMCP/Tools.swift. However, descriptions are German-language and brief (averaging ~80 chars), parameter descriptions lack depth and format guidance, schemas lack enums/constraints, output schemas are entirely undocumented, and there is no error handling guidance. The tool names follow verb_noun patterns adequately (rename_files, suggest_names, watch_folder), but descriptions do not explain WHEN to use each tool vs alternatives, WHAT happens to state, or error recovery paths. Parameters like 'provider' accept free-form strings instead of enums, 'apiKey' is exposed as a parameter (security risk), and critical parameters like 'template' and 'format' lack examples or constraints. No tool documents what it returns, making downstream chaining difficult. Tool composition is reasonable (separate suggest vs rename), but descriptions are insufficient for LLM selection and parameter guidance.
Gibt den aktuellen App-Status und Einstellungen zurück
Zeigt die Umbenennungs-Historie
Zeigt die aktuellen Umbenennungsregeln (Format, Datum, Casing, Kategorien)
Benennt Dateien um: Analysiert den Inhalt mit KI und benennt die Dateien mit beschreibenden Namen um
Macht eine Umbenennung rückgängig
Wechselt den KI-Provider (Claude, OpenAI, Gemini, Ollama, Apple)
API key exposed as tool parameter: set_provider accepts 'apiKey' as input, violating secret-injection pattern. Agent traces log all parameters, leaking credentials.
Output schemas entirely undocumented. Tools describe what they do but not what structure they return (fields, types, array vs object). LLMs cannot plan downstream calls or extract the right data.
Free-form string parameters instead of enums. 'provider' should be enum [Claude, OpenAI, Gemini, Ollama, Apple]. 'dateFormat', 'casing', 'separator' in set_rules should be enums. Free-form invites hallucinated invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
Ändert die Umbenennungsregeln
Schlägt neue Dateinamen vor ohne umzubenennen
Fügt einen Ordner zur Überwachung hinzu
Descriptions lack action clarity and state-change warnings. 'rename_files' description does not warn that this is DESTRUCTIVE and modifies the filesystem. Error handling guidance absent, no recovery paths for failures.
Parameter descriptions lack depth and format guidance. 'template' in rename_files/suggest_names has no examples of valid syntax. 'format' in set_rules lists examples ('e.g. {datum}{sep}...') in description instead of a formal pattern/constraint. 'limit' in get_rename_history has no range (1 - 1000?).
Tool descriptions are in German and brief (~80 chars avg). Baseline for A+ tools is 194 chars with LLM-optimized language (WHAT, WHEN, WHY, prerequisites). Current descriptions lack selection context.
No error handling guidance. Tools do not document retryable vs fatal errors, recovery paths, or actionable error messages. E.g. set_provider with invalid API key, what does the LLM do next?
No idempotency or confirmation guards on destructive operations. rename_files and watch_folder with autoRename=true modify state, no dry-run, no confirmation step. Agents can accidentally batch-rename hundreds of files.
Parameter relationships undocumented. In set_rules, does 'format' define which of dateFormat/casing/separator apply? What if format='{name}' but dateFormat and casing are also set? Ambiguity leads to misuse.