Tool definitions are inferred from test code rather than explicit registration. No input schemas visible in source, only parameter names and descriptions in test fixtures. Descriptions are present but generic (10-50 chars). Critical security issues: light_bash and light_ssh expose command execution without validation guidance. light_file lacks operation enum constraints. No output schemas documented. Error handling absent. Tool names lack clear verb-noun structure (light_* prefix is decorative, not action-oriented).

• Add explicit JSON Schema definitions for all tool inputs in server.go Register() calls. Include type, description, enum, minLength, maxLength, pattern for each parameter. Example: {"command": {"type": "string", "description": "Shell command to execute (no pipes, redirects, or subshells)", "minLength": 1, "maxLength": 4096}}
• Document output schemas for each tool. Specify returned fields, types, and structure. Example for light_bash: {"type": "object", "properties": {"stdout": {"type": "string"}, "stderr": {"type": "string"}, "exit_code": {"type": "integer"}}}
• Rename tools to verb-noun pattern: execute_bash_command, read_file, edit_file, copy_file_scp, search_logs. This enables LLMs to infer intent from the name alone.
• Add input validation and error guidance. For light_bash/light_ssh, reject commands containing pipes, redirects, or subshells; return 'Command contains forbidden characters: |, >, <. Use separate tool calls instead.' For light_file, validate operation is one of [read, edit, list] and return enum violation errors.
• Expand descriptions to 50-150 characters with WHEN/WHY context. Example: 'Execute a shell command with bounded output (max 10KB). Use for file inspection, process checks, or system queries. Does not support pipes or redirects, call multiple times for complex workflows.'