Loading ToolBench
Real-time system intelligence for AI agents — exposes 17 diagnostic tools for CPU, RAM, disk, network, processes, hardware health, developer stack, and system logs
DivLens provides 17 system diagnostics tools with basic descriptions but significant quality gaps. All tools are READ_ONLY, which is good for safety, but most lack detailed parameter descriptions, output schemas, and error handling guidance. Tool names follow verb_noun convention (get_*, scan_*), which is correct. However, descriptions are often generic (e.g., 'Get real-time system metrics') without explaining WHEN to use each tool or what distinguishes it from similar ones. Only 6 of 17 tools show visible input schemas in the provided code; the rest lack documented parameter types and constraints. No tool shows documented output schemas. Error handling is not evident in the samples provided. The server appears to be a system monitoring toolkit rather than an agent-optimized tool collection.
Get advanced storage statistics including fragmentation, compression, and optimization metrics
Get developer tools stack including language runtimes, package managers, and installed packages
Get list of installed drivers and their versions
Get summary of files by type from the storage inventory database
Get comprehensive hardware diagnostics including CPU, memory, thermal, and power information
Get real-time system metrics (CPU, RAM, disk I/O, network I/O)
Get network configuration including interfaces, IP addresses, DNS, and routing information
Get network diagnostics including active connections, listening ports, and network health
11 of 17 tools lack visible input schemas. Only 6 tools (get_process_list, scan_storage_inventory, get_specific_file_type, scan_directory, recall_memory, get_system_logs) show parameter definitions. The remaining 11 have no documented input structure, violating the schema requirement.
Tool descriptions are generic and under 50 characters for 11 tools (e.g., 'Get real-time system metrics', 'Get storage health status'). These lack context for LLM selection and do not explain WHEN to use each tool vs. similar ones (e.g., get_storage_health vs. get_storage_diagnostics vs. get_advanced_storage_stats).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 34 | <=2025-11-25 | v2 |
Get list of running processes with CPU and memory usage
Get detailed list of files of a specific type from the inventory database
Run comprehensive storage diagnostics including I/O performance, error rates, and health checks
Get storage health status including disk usage, temperature, and SMART data
Get comprehensive system identity and configuration including OS, architecture, hostname, and installed software
Get system logs and event information from the system log database
Query the vector memory database for relevant system information based on semantic search
Scan a directory and return its contents with file metadata
Scan and inventory storage contents, categorizing files by type and location
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields without knowing what each tool returns. This violates the pattern:response-shaper requirement.
Three tools (get_storage_health, get_storage_diagnostics, get_advanced_storage_stats) have overlapping names and purposes. LLMs cannot distinguish when to call each. Consolidate or clarify the distinction in descriptions.
No error handling guidance visible. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. This violates pattern:recovery-guide.