Loading ToolBench
Model Context Protocol (MCP) server for administering wg-easy (WireGuard Easy) v15+ instances
wg-easy-mcp has 8 tools with consistent naming (verb_noun pattern) and reasonable descriptions. All tools are properly scoped and follow clear patterns. However, parameter schemas are largely empty (tools accept minimal input), descriptions lack specificity about prerequisites and error modes, and output schemas are not documented. The server implements read-only mode via tool filtering which is architecturally sound, but tool definitions themselves do not expose schemas for LLM introspection. Parameter descriptions exist but are sparse; most tools (5/8 read-only) have trivial input specs. Error handling guidance is missing, no recovery hints for LLMs.
Create a new WireGuard client
Delete a WireGuard client
Get details of a specific WireGuard client including configuration and statistics
Get the WireGuard configuration file (.conf) for a client
Get the QR code (as SVG) for a WireGuard client configuration
Get information about the wg-easy instance: release/update status, general settings and the WireGuard interface configuration. Secret fields (private keys, passwords) are redacted.
List all WireGuard clients on the wg-easy instance, with optional filtering by name
Input schemas for all 8 tools are either missing or not visible in source code provided. Code references src/tools/*.ts files but schema definitions are not shown. Cannot verify that parameters have type annotations, enums, min/max constraints, or descriptions required for LLM parameter validation.
Output schemas are not documented for any tool. LLMs cannot plan downstream tool calls or know what fields to expect from responses. Critical for composition and for understanding what data is returned by list operations.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2025-06-18+ | v2 |
Update an existing WireGuard client's configuration
Tool descriptions lack recovery guidance and error handling context. E.g., 'Get details of a specific WireGuard client...' does not explain what happens if the client ID is invalid, whether a retry is appropriate, or how to discover valid client IDs. LLMs receive no guidance on failure modes.
Destructive operations (delete_client) lack explicit confirmation or dry-run safeguards documented in schema or description. While server.ts shows mcp-approval integration, the tool definition itself does not hint that confirmation is required.
Tool descriptions for write operations (create_client, update_client) do not specify what parameters are required vs optional, what format values must take, or what constitutes a valid client name/configuration.
list_clients description mentions 'optional filtering by name' but does not document the parameter name, whether it is a substring match or exact match, or whether the list is paginated with limit/offset support.
No indication in tool descriptions about whether responses are paginated, how many items are returned by list_clients, or what happens if a large number of clients exist. Baseline: list tools should declare pagination and result limits.