Single tool 'send_contact_form' has a clear action verb and well-structured input schema with proper types and descriptions. However, the tool description (89 chars) is below the 194-char baseline for production tools and lacks critical context about side effects, prerequisites, and error recovery. Output schema is not documented. No error handling guidance for LLM recovery. The tool performs a write operation (sends email) but lacks idempotent/destructive annotations and confirmation patterns.

• Expand tool description to 150-250 chars: 'Sends a contact form submission via Resend email service. Validates name (max 120 chars), email (valid format, max 320 chars), and message (max 10000 chars). Returns {received: true} on success. Requires RESEND_API_KEY environment variable. Errors: 503 if service not configured, 502 if Resend API fails, 400 if validation fails.'
• Document output schema explicitly: success case {received: boolean}, error cases {error: string}, and map HTTP status codes (200, 400, 502, 503) to LLM-actionable error types (user-fixable, retryable, fatal).
• Add error recovery guidance: 'If error is "Email service is not configured yet", this is a deployment issue, ask the user to set RESEND_API_KEY. If "Email service unavailable", retry after 30 seconds. If validation error, correct the input and retry.'
• Add tool annotations: mark as destructiveHint=true (sends email, not reversible) and idempotentHint=false (repeated calls send duplicate emails). This helps LLMs reason about retry safety.
• Enhance parameter descriptions with inline constraints: 'Contact name (1-120 characters, alphanumeric + spaces)' instead of relying on schema maxLength alone.