Strong schema definitions with Zod validation and tool annotations (destructiveHint/readOnlyHint). All 15 tools have descriptions and input schemas. Naming follows verb_noun pattern consistently (send_transaction, bulk_begin, etc.). However, parameter descriptions lack detail on constraints (e.g., email format validation rules, max recipient counts for CC/BCC not stated in descriptions). Output schemas are not documented in the tool definitions. Error handling guidance is minimal, no recovery hints for common failures. Security is well-handled (no secrets in params, environment-based config). Composition is clean: each tool has one responsibility, and tool chains are clear (bulk_begin → bulk_update_recipients → bulk_commit_*).

• Document output schemas for all tools. Add a 'Returns' section to each tool description or create a separate schema document. Example: 'Returns: {delivery_id: integer, status: string, created_at: ISO8601, recipient_count: integer}'.
• Enhance parameter descriptions with explicit constraint text. Change 'Sender email address (6-254 chars, valid email format)' to 'Sender email address. Must be 6 - 254 characters, valid RFC 5322 format (e.g., [email protected]). Invalid format returns error code 400.'
• Add recovery hints to destructive tool descriptions. E.g., 'If commit fails with status INVALID_RECIPIENTS, call blastengine_bulk_preview to review recipient list, then retry.'
• Implement a dry-run or confirmation pattern for send_transaction and bulk_commit_* tools. Add an optional 'dry_run: boolean' parameter that validates without sending, or require explicit 'confirm: true' parameter.
• Clarify pagination defaults in list tool descriptions. E.g., 'Returns up to 100 deliveries per page (default size=100, max 1000). Use page parameter to iterate; total count is included in response.'

Inferred effective spec: 2025-06-18+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry