safe-encryption provides clear tool names, reasonable descriptions, and well-formed JSON schemas for all 5 tools. However, several definition quality gaps prevent a higher score: (1) descriptions are inconsistent in depth and some lack guidance on when/why to use tools; (2) parameter descriptions are sparse or missing for some options (e.g., 'aead' enum in safe_encrypt lacks explanation of when to choose each cipher); (3) no documented output schemas, callers don't know what fields to expect from encryption operations; (4) no error handling guidance in tool descriptions, LLMs won't know what to do if decryption fails or a key is not found; (5) parameter dependencies and mutual exclusivity are undocumented (e.g., plaintext vs input_file in safe_encrypt, ciphertext vs input_file in safe_decrypt); (6) no description of file size limits, output format details, or key discovery behavior. Tools are well-named and follow verb_noun convention, but descriptions fall short of the 'prompt-engineering' standard (explain WHAT, WHEN, and prerequisites). All schemas have type definitions and basic constraints (enums on key types and algorithms), meeting the floor for 'fair' quality. Lacks the structured output documentation and error recovery guidance expected of 'good' tools.

• Add an 'outputSchema' field to each tool definition documenting the expected return structure. For safe_encrypt, return {encryptedText: string, outputPath?: string, algorithm: string}. For safe_decrypt, return {plaintext: string, outputPath?: string}. For safe_keys, return {keys: [{name: string, type: string, fingerprint: string}]}.
• Document mutually exclusive parameters explicitly in descriptions: 'Either provide plaintext (encrypted inline) or input_file (encrypted from disk), not both.'
• Expand parameter descriptions to clarify constraints and guidance: 'aead: Symmetric cipher algorithm. AES-256-GCM is hardware-accelerated on most platforms (default). ChaCha20-Poly1305 is portable and recommended for low-power devices.'
• Add recovery guidance to safe_decrypt description: 'Decryption fails if the wrong password is provided, the required private key is not in ~/.safe/keys/ or ~/.ssh/, or the .safe file is corrupted. Check available keys with safe_keys tool and retry with the correct password.'
• Clarify safe_keygen behavior: 'Generates a new keypair and stores it in ~/.safe/keys/{name}-{type}.{pub,priv}. If a key with the same name and type already exists, the tool returns an error rather than overwriting. Returns the path to the generated public key.'
• Document safe_info output format: 'Returns a JSON object with {recipients: string[], algorithms: {symmetric: string, asymmetric: string}, keyCount: number}, useful for checking recipient lists before reencryption.'
• Add limits and performance notes: 'safe_encrypt supports files up to 50 MB (configured in runSafe options). For larger files, consider streaming or splitting into chunks.'