Server has 23 tools with mostly complete schemas and descriptions in Russian. Naming follows verb_noun pattern (get_, list_, set_, add_, remove_, bind_, unbind_, export_, run_). Descriptions are detailed and contextual, averaging ~150 chars, well above the 34-char baseline minimum. However, several critical gaps: (1) descriptions lack actionable recovery guidance for error cases; (2) some parameters missing type constraints (e.g., 'target' in add_route accepts string but no format/pattern specified); (3) no documented output schemas for any tool, LLMs cannot predict response structure; (4) parameter descriptions occasionally reference external context (RCI ids, interface names) without explaining how to discover them; (5) no explicit idempotency or retry guidance for write operations. Read-only tools (11/23) are well-described. Write tools (12/23) lack confirmation/dry-run patterns except where explicitly noted (set_wifi_password, add_port_forward, etc. do have confirm/dryRun). Tool composition is sound, each tool has one responsibility. Security: credentials injected via environment (config.ts), not exposed as parameters. Batch file parser (routes-batch.ts) implements fail-closed validation, preventing command injection.

• Document output schemas for all tools. For list_* tools, specify: array of objects with fields (e.g., list_devices returns [{mac, ip, name, interface}]). For get_* tools, specify returned object structure. Use JSON Schema format in tool registration.
• Add format/pattern constraints to string parameters. E.g., 'target' in add_route: 'Interface name (e.g., Wireguard0) or IPv4 gateway (e.g., 192.168.1.1)'. Use regex patterns in schema where applicable.
• Add pagination to list_* tools: include 'limit' (default 20, max 100) and 'offset' (default 0) parameters. Return total_count in response so agents know if more results exist.
• Enhance error descriptions with recovery guidance. E.g., 'If you see "execute denied", the router login lacks admin privileges. Update ROUTER_LOGIN/ROUTER_PASSWORD in config and retry.' Reference check_firmware_update's pattern for other tools.
• Document tool dependencies in parameter descriptions. E.g., set_wifi_password description: 'To find interfaceId, call get_interfaces first and look for Wi-Fi entries.' This guides multi-step planning.