Loading ToolBench
MCP server for AxiomOS Labs providing dynamic skill loading and tool execution with structured PDDL metadata responses
The AxiomLabs MCP server exhibits significant quality gaps across the definition rubric. While all 6 tools have names starting with action verbs and basic descriptions, the descriptions are uniformly terse (10-50 characters), well below the 194-character baseline for production tools. Input schemas are present but lack critical details: parameters have type definitions but most lack descriptions or constraints. Output schemas are entirely undocumented, the source shows no return type declarations or structured output guidance. Error handling is absent from all tool definitions. Security considerations (particularly concerning for tools like `get_admin`, `remove_file`, and `move`) are not addressed. The tool composition is reasonable (each does one thing), but the definitions lack the LLM-friendly detail needed for reliable agent selection and parameter binding.
Compress a file into an archive
Get administrative privileges or check admin status
Move a file from one folder to another
Remove a file from a folder
Rename a file in a folder
Scan and list contents of a folder
All tool descriptions are extremely terse (10-50 chars), well below the 194-char production baseline. Descriptions lack context on WHAT the tool does, WHEN to use it, and any prerequisites. Example: 'Scan and list contents of a folder' provides no guidance on output format, pagination, or handling of nested structures.
Output schemas are completely undocumented. Tools return results (evidenced by the 'pddl_delta' metadata field mentioned in the header), but no schema is visible for what agents should expect. LLMs cannot plan downstream calls without knowing the response structure.
Most parameters lack descriptions. The 'folder' parameter in scan has a description, but many do not clearly explain constraints. E.g., does 'folder_name' in remove_file accept absolute paths, relative paths, or symlinks? Are there allowed characters? Size limits?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
No error handling guidance. Tools like remove_file (DESTRUCTIVE) and move (WRITE) offer no recovery hints. Agents need to know: what if the file doesn't exist? What if permissions are denied? Should they retry, ask the user, or abort?
get_admin tool is poorly named and under-specified. Does 'Get administrative privileges' mean the tool GRANTS admin status, CHECKS if the caller is admin, or REQUESTS elevation? The name 'get_admin' is ambiguous, should it be 'check_admin_status' or 'request_admin_elevation'? No parameters provided, so unclear what it operates on.
No security scoping or permission gates declared. The move, remove_file, and compress tools perform state-changing operations on the filesystem, but no tool description mentions required permissions (read:fs, write:fs, delete:fs), audit logging, or validation of file paths against traversal attacks.
No confirmation or dry-run pattern for destructive operations. remove_file is marked DESTRUCTIVE but offers no dry-run mode or confirmation step. Agents can permanently delete files without a safety mechanism.
Parameter names are sometimes inconsistent or ambiguous. compare 'folder' (scan, compress) vs 'folder_name' (remove_file) vs 'from_folder'/'to_folder' (move). This inconsistency increases cognitive load for agents and risks parameter binding errors.
No input validation constraints visible. Numeric limits, regex patterns, or character restrictions are not declared. E.g., does archive_name in compress accept '..' or symlinks? Can file_name be an absolute path or must it be relative?