Two tools with complete input schemas and reasonable descriptions. faxdrop_send_fax has 11 parameters with types and descriptions; faxdrop_get_fax_status is minimal but correct. Descriptions are adequate (80-160 chars) but lack actionable context for LLM selection. No output schemas documented. Error handling and recovery guidance absent. Parameters lack constraints (e.g., phone format validation, file type restrictions stated only in description, not schema). No tool annotations (readOnlyHint/destructiveHint). Naming is clear (verb_noun pattern). Security: API key injected server-side (good), but file path parameter accepts user input without visible validation in schema.

• Document output schemas for both tools. Example: faxdrop_send_fax returns {faxId: string, status: 'queued'|'sent'|'failed', cost: number, estimatedDeliveryTime: string}. faxdrop_get_fax_status returns {faxId: string, status: string, sentAt: string, deliveredAt?: string, failureReason?: string}.
• Add destructiveHint: true and idempotentHint: false to faxdrop_send_fax schema to signal that this tool sends real faxes and charges money. Pair with dryRun parameter (already present) in description: 'Set dryRun=true to validate without sending.'
• Enhance faxdrop_send_fax description: 'Sends a real fax via FaxDrop API (charges apply). Accepts PDF/DOCX/JPEG/PNG files from the outbox directory. Use dryRun=true to validate first. Returns faxId for status polling. Requires valid international phone number (+1-15 digits).'
• Add pattern constraint to recipientNumber: pattern: '^\+[1-9]\d{1,14}$' (E.164 format). Add pattern to filePath: pattern: '^/app/outbox/[a-zA-Z0-9._-]+\.(pdf|docx|jpeg|jpg|png)$' to enforce outbox jail.
• Add error recovery guidance to descriptions. Example: 'If fax fails, call faxdrop_get_fax_status(faxId) to check reason. Common failures: invalid number format, file too large (>10MB), API quota exceeded. Retry after 60 seconds if status is "queued".' Include this in tool description or as a separate error_handling field.