Three tools with identical schemas and minimal descriptions. Descriptions are 80-90 chars, below the 194-char baseline for production tools. No output schemas documented. Parameter descriptions are generic ('where the issue is located', 'details of the issue') without actionable constraints. No error handling guidance. Tools are well-named (verb_noun pattern: send_*_complaint) but lack the depth needed for reliable LLM selection and execution.

• Expand tool descriptions to 150-250 chars. Example: 'electricity_complaint: Send a complaint email to the electricity authority about power outages, brownouts, or billing issues. Optionally attach a cartoonized photo of the problem. Requires SMTP credentials in env vars. Returns email_id and cartoonization_status (success|skipped|failed).'
• Add parameter-level descriptions with format and validation rules. Example: location: 'Street address or landmark (e.g., "123 Main St, Apt 4B" or "near Central Park"). Required for authority routing.' authority_email: 'Valid email address of the department (e.g., "[email protected]"). Must be reachable.'
• Document the output schema explicitly in the tool description or as a separate schema field. Example: 'Returns {email_id: string, sent_at: ISO8601, cartoonization_status: "success"|"skipped"|"failed", error?: string}'.
• Add error handling guidance. Example: 'If SMTP fails, check SMTP_HOST and SMTP_PASSWORD env vars. If image cartoonization fails, the email is still sent without attachment. If authority_email is invalid, returns error: "Invalid email format".'
• Distinguish the three complaint types in descriptions. Example: electricity_complaint for power/billing issues, road_complaint for potholes/pavement, water_complaint for leaks/contamination. This helps LLMs select the right tool.