Single tool with comprehensive parameter schemas and detailed descriptions. The tool name 'encrypt_message' is clear and action-oriented, following verb_noun convention. The description is extensive (450+ chars) and explains the tool's purpose, requirements, and complex constraints. Input schema is fully defined with Pydantic models (RotorConfig, ReflectorConfig) including type definitions and field descriptions. However, the description is verbose and could be more concise (ideal range 50-200 chars per pattern:tool-description). Output schema is undocumented, no specification of what the encrypted/decrypted message looks like or what fields are returned. Error handling is missing, no guidance on what happens with invalid machine models, malformed configurations, or constraint violations. The tool handles complex domain logic (Enigma machines with multiple variants, rotors, reflectors) but expects exact parameter formatting without validation feedback.

• Document the output schema explicitly. Specify: 'Returns a string containing the encrypted/decrypted message (uppercase letters for M3/M4/I variants, digits for Z, Swedish letters for B_A133). Example output: "HELLOWORLD". No pagination or metadata is returned.'
• Refactor the description to be more concise. Current structure: 'Encrypt or decrypt a message using a specified Enigma machine configuration.' (brief, 67 chars). Then move machine-model requirements and rotor constraints into parameter descriptions where they belong, keyed to the specific parameters.
• Add structured error handling. Instead of generic ValueError(), return a tool response with a 'success' field and 'errors' array. E.g., '{"success": false, "errors": [{"field": "machine_model", "message": "Unsupported machine model: Enigma X. Valid models: M3, M4, I, ..."}]}'.
• Clarify the 'message' parameter type. If Enigma Z requires digits, use separate type descriptions: 'For Enigma Z: a string of digits only ("1234567890"). For all others: uppercase ASCII letters ("A-Z"). Type: string.' Avoid Union[str, int] which invites type confusion.
• Add machine-model-to-rotor validation in the schema or tool logic with actionable errors. E.g., 'M4 requires exactly 4 rotors ([standard, standard, standard, Greek]). Got 3 standard rotors.'
• Consider batching encrypted/decrypted messages if LLMs need to process multiple Enigma settings. A tool like 'encrypt_message_batch' would reduce round-trips and token overhead.
• Include a 'dry_run' or 'validate_config' parameter to let LLMs verify a configuration before committing to encryption. This reduces failed attempts and clarifies intent.