zefer-cli presents a well-structured encryption-focused tool suite with strong cryptographic backing and detailed parameter schemas. Tool naming is action-verb based and clear (encrypt, decrypt, keygen, analyze_password, inspect). All 5 tools have descriptions ranging from 90-300+ characters, exceeding the 10-character minimum. Input schemas are comprehensive with proper JSON Schema type definitions for all parameters. However, output schemas are NOT documented in the source, the code lacks explicit schema definitions for what each tool returns, forcing LLMs to infer structure from response handling logic. Error handling is present but minimal; no recovery guidance or error classification patterns. Tool descriptions focus on technical capability but lack explicit "WHEN to use" guidance. One tool (zefer_encrypt) accepts dual passphrases and secondary authorization features that introduce parameter interdependency not documented. Overall, the security-focused domain and parameter completeness elevate this above average, but missing output documentation and recovery guidance prevent a higher score.

• Document the output schema for each tool in explicit JSON Schema format. For zefer_encrypt, clarify: does success return { path: string, size: number } or { success: true, fileName: string }? For zefer_analyze_password, document the structure of the 'weaknesses' array and the compliance object.
• For zefer_encrypt, add a parameter description table in the tool description explaining valid combinations: (passphrase alone), (passphrase + secondPassphrase), (passphrase + revealKey), (passphrase + question + questionAnswer). State which combinations are mutually exclusive.
• Add error handling guidance: 'If decryption fails with max_attempts_exceeded, the file is locked. Try again later or use a different file. If passphrase_invalid, verify spelling, no recovery without the correct passphrase.'
• Expand descriptions with use-case guidance. E.g., 'zefer_keygen: Call this to generate secure passwords, API keys, or tokens for users. Use mode=base58 for URLs, mode=pin for human-memorable codes. Use mode=uuid when the system generates its own IDs.' This helps LLMs know when to invoke each tool.
• Add parameter descriptions for inputPath/outputPath clarifying: 'Relative paths are resolved from the current working directory. Use absolute paths for clarity. Path traversal attempts (../) are rejected for security.' This surfaces the sanitization logic.
• Implement explicit error messages mapping to LLM-actionable recovery steps. Catch 'file not found' and suggest 'Use zefer_inspect first to verify the file path', or catch 'passphrase invalid' and suggest 'Double-check the passphrase, decryption is deterministic and will not succeed with wrong credentials.'