Loading ToolBench
Multi-server MCP gateway with aggregating proxy, code execution sandbox, and Docker-based tool hosting
The FusionAL ecosystem contains 14 tools spread across multiple services with highly inconsistent quality. Tool naming is reasonable (verb-noun conventions mostly followed), but descriptions are often generic or incomplete. Parameter schemas are present for most tools but lack depth, type definitions exist but descriptions are frequently missing or trivial. No visible output schemas are documented. Error handling is minimal. The codebase shows evidence of basic MCP integration but lacks the production-grade discipline needed for A or B tier scoring. Most tools fall in the 35-55 range; the ecosystem averages to C grade (fair, significant gaps).
Add a regex pattern to the command blocklist checked by proc_start. Patterns are additive and case-insensitive; there's no tool to remove the built-in defaults, by design. Args: - pattern (string): A valid regular expression (JavaScript syntax) to block. Returns: { added: true, pattern } or an error if the pattern doesn't compile.
View this server's current security configuration: which directories are accessible, which command patterns are blocked, and the default shell. Returns: { allowedRoot, allowedDirectories, blockedCommandPatterns, defaultShell }. allowedRoot is a hard ceiling set at server startup (ALLOWED_ROOT env var) and can never be widened at runtime.
Narrow (or reset) which directories filesystem/process tools can touch. Every directory must already be inside the hard ALLOWED_ROOT ceiling set at server startup — this tool can restrict access further, never widen it beyond that root. Args: - directories (string[]): Absolute paths, all must resolve inside ALLOWED_ROOT. Returns: { accepted: string[], rejected: string[] } — rejected entries were outside ALLOWED_ROOT and were ignored.
Count total lines in a file.
roll_stats has NO input schema (empty object {}) and minimal description (11 characters).
Most tools lack documented output schemas. LLMs cannot infer what fields to expect from responses. Examples: roll_dice, count_lines, get_weather return unspecified structures. This blocks downstream tool composition and forces LLMs to reason about undocumented responses.
Parameter descriptions are missing or generic across most tools. Examples: flip_coin's 'count' param described only as 'Number of coins to flip' (no range, type info beyond JSON schema); roll_check's 'modifier' param has no hint of valid range; get_weather's 'location' param lacks examples of supported formats (city name, coordinates, etc.).
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
Flip one or more coins (heads or tails).
Get file metadata including size, modification time, and permissions.
Get a multi-day weather forecast for a location.
Fetch current weather for a specified location.
List files in a directory, optionally filtered by extension.
Parse and format raw weather JSON data.
Make a skill check against a DC (Difficulty Class).
Roll dice using standard notation like 1d20, 2d6+3, 3d8-2.
Roll D&D ability scores using 4d6 drop lowest method.
Search for a text pattern in a file (case-insensitive).
Tool descriptions are frequently too brief (< 50 chars) and lack context for when/why to use them. Examples: 'Roll dice using standard notation like 1d20, 2d6+3, 3d8-2' (roll_dice) tells WHAT but not WHEN; 'Flip one or more coins (heads or tails)' (flip_coin) is action but no use case; 'Get file metadata' (get_file_info) is vague, which metadata? All fields? Return type?
No error handling guidance visible. Tools do not document what errors can occur, how to recover, or which are retryable. Example: get_weather will likely fail for unknown locations, but no tool tells the LLM what to do (try a synonym? ask user for clarification? list available locations?). Agents cannot plan recovery.
Parameter type consistency issues: roll_dice, flip_coin, roll_check, get_forecast all accept numeric inputs (dice notation, count, DC, days) as strings with defaults like '1', '1', '15', '5'. This invites parsing errors and requires LLMs to understand type coercion. Should be typed as integers in schema.
File tools (count_lines, get_file_info, search_text, list_files) lack security documentation. No mention of path traversal guards, directory access restrictions, or allowed roots. The commander-mcp-server shows ALLOWED_ROOT env var exists, but the Python file-utils tools give no hint of scope limits. Agents don't know if they can access /etc/passwd or only project directories.
Unclear input validation. Examples: search_text's 'pattern' is described as 'Text pattern to search for' but doesn't clarify if it's literal string, regex, or fuzzy match. roll_dice's 'notation' param says 'Dice notation string' but doesn't specify what formats are valid (1d20, 2d6+3 yes; 1d2o no?). LLMs will guess wrong.
No tool composition hints. If an agent wants to list files, read one, search inside it, it must call three tools sequentially. No tool returns file_path in a format the next tool accepts, or hints about common workflows. Each tool is designed in isolation.