Loading ToolBench
MCP Server for TencentOS Server — system telemetry, diagnostics, and recommendations
Server has 25 well-named, read-only tools with consistent verb_noun naming (query_, list_, get_, check_, assess_, analyze_). All tools have descriptions (avg 150 chars, within baseline 34-392). Input schemas are present with type definitions and parameter descriptions. However, output schemas are NOT documented in the source code, LLMs cannot see what fields to expect from responses. Error handling is minimal; no recovery guidance or actionable error messages visible. Tool descriptions lack dependency hints and prerequisites. Some parameters (e.g., workload_hint in multiple tools) repeat across tools without clear composition guidance.
Analyze system tuning parameters against best practices for the detected workload type. Returns current values, recommended values, and optimization suggestions for kernel, network, memory, and filesystem parameters.
Assess the impact of available patches: which packages have updates, what severity, whether they require reboot, and which running services are affected. Scans running processes to detect if they are actively using outdated libraries.
Query operation audit trail: who logged in, who ran sudo, what was changed. Aggregates data from auditd, /var/log/secure, last/lastb, and sudo journal. Marks high-risk operations and provides per-user activity summary. NOTE: This is for compliance/audit purposes, NOT for vulnerability or patch scanning.
Check system compliance against security best practices: auditd status, audit rules, password policy, SSH configuration, sudo logging, failed login attempts. Returns compliance score (0-100) and findings.
Check current kernel parameters and their recommended values. Returns a list of parameters with current values, recommended values, and status (optimal/suboptimal/risky).
Output schemas not documented. LLMs cannot see what fields tools return (e.g., diagnose_system returns health_score, problems, recommendations, but this is not visible in the schema). Forces agents to guess field names and risks extraction errors.
No error handling guidance. Tools lack recovery hints (e.g., 'If auditd is not running, enable it with systemctl start auditd'). Errors are likely raw exceptions, not actionable messages for LLMs.
Repeated parameters across tools without composition guidance. workload_hint appears in analyze_system_tuning, get_workload_profile, and check_kernel_parameters. No description of when to call get_workload_profile first vs. passing workload_hint directly.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | <=2025-11-25 | v2 |
Check dependencies and conflicts for a specific patch or package update. Identifies if applying a patch would break other packages or services.
Check CPU, memory, IO, and network resource pressure. Returns load averages, memory usage, disk usage, and PSI (Pressure Stall Information) metrics if available.
Compare patch status between two points in time or between current and recommended state. Shows which patches were applied, which are pending, and impact summary.
Comprehensive system health diagnosis: collects logs from journalctl, dmesg, systemd, and /proc; correlates errors across sources; scores system health 0-100; identifies problems and provides recommendations.
Get CPU information: model name, number of cores/threads, architecture, frequency, and current load averages.
Get disk usage for all mounted partitions. Returns device, mount point, filesystem type, size, used, available, and usage percentage.
Extract error events from journalctl and dmesg, correlate across sources, and return a timeline sorted by timestamp. Aggregates duplicate errors.
Get kernel version history: all installed kernel versions, installation times, whether each is currently running, and any loaded hotfixes. Useful for tracking kernel updates and security patches.
Get memory information: total, used, free, available, usage percentage, and swap statistics.
Get patch/package installation history: which packages were installed/updated/removed, when, by whom, and return code. Useful for tracking changes and compliance audits.
Get privileged (sudo/su/root) operation records from audit logs and system journals. Filters for high-risk operations and provides timeline.
Detect and profile the current system workload: CPU load, memory usage, IO wait, network connections. Returns workload type classification (cpu_intensive, io_intensive, network_intensive, mixed, idle) and detailed metrics.
List block devices (disks, partitions) with their size, type, mount point, and filesystem type.
List active network connections with protocol, local/remote addresses and ports, connection state, and associated process.
List network interfaces with their status, IP addresses (IPv4 and IPv6), and MAC addresses.
List running processes with optional filtering and sorting. Returns PID, user, CPU%, memory%, VSZ, RSS, state, start time, and command.
List all available security advisories (CVE, RHSA, TESA) for the system. Returns advisory ID, affected packages, severity, and CVE IDs.
List systemd services with their status. Returns service name, load state, active state, sub state, and description.
Query system logs from journalctl with optional filters. Supports filtering by unit, priority, and time range.
Get basic system information: hostname, OS name/version, kernel version, architecture, uptime, and last boot time.
Some parameter descriptions lack format/constraint details. E.g., baseline_date in compare_patch_status accepts '2026-04-01' or '30 days ago' but no regex pattern or format spec is visible. LLMs may pass invalid formats.
No pagination or result limits documented for list_* tools. list_processes defaults to 20, list_network_connections to 50, but list_services has no visible limit. Large result sets risk context window exhaustion.