Server has 4 tools with explicit schemas and descriptions. Naming follows verb_noun convention (agent_mail_discovery, list_postalform_tools, validate_letter_mail, create_letter_checkout_draft). Schemas are well-structured using Zod with proper constraints (min/max lengths, enums, email format). However, descriptions are brief (10-80 chars) and lack actionable context for LLM tool selection. Parameter descriptions exist but are minimal. Error handling is absent, no guidance on retryability, user-fixable vs fatal errors, or recovery paths. Output is JSON text only, not structured with documented field types. Missing idempotency hints and confirmation patterns for the destructive create_letter_checkout_draft tool.

• Expand tool descriptions to 100-200 chars. Example: 'agent_mail_discovery: Returns PostalForm API endpoints, MCP URL, and documentation links. Call this first to discover available mail services and integration options.' This tells LLM WHEN and WHY to use it.
• Add structured output schema documentation. Define return type for each tool (e.g., agent_mail_discovery returns {product, mcpEndpoint, developerDocs, ...}). Document field types and required fields so LLMs can chain calls.
• Implement error handling with recovery guidance. Catch PostalForm MCP connection failures and return: 'PostalForm MCP unreachable at {url}. Verify POSTALFORM_MCP_URL env var and network connectivity. Retry in 30s or contact support.' Pattern: recovery-guide.
• Add idempotency and confirmation patterns. For create_letter_checkout_draft, support a 'dry_run' parameter that validates without creating a draft. Return estimated cost and confirmation URL. Require explicit confirmation before actual creation.
• Document parameter relationships. E.g., 'sender_address_manual and recipient_address_manual: state is required for US/CA (countryCode=US|CA), optional for others. line2 is optional; omit if not applicable.' This prevents LLM errors from missing required fields.