Server has 9 well-structured tools with complete JSON schemas and descriptions in Portuguese. All tools have proper input validation via Zod. However, descriptions are inconsistent in depth and some lack actionable guidance for LLM selection. Parameter descriptions are present but generic in places. No output schemas documented. Error handling exists but lacks recovery guidance. Tool naming follows verb_noun convention correctly (search, get, create, update, add). Composition is sound, tools are single-responsibility and chainable via ID returns.

• Document output schemas for all tools. Add a 'Returns' section to each tool description listing key fields (e.g., 'Returns: {id, title, state, created_at, articles[]}') so LLMs know what to expect and can chain calls.
• Enhance error handling in dispatch.ts. Categorize errors as retryable (network timeout, rate limit) vs user-fixable (invalid parameter, not found) vs fatal (auth failure). Return actionable messages: 'Ticket not found. Try zammad_ticket_search() to find the correct ID.'
• Expand descriptions for directory tools. Add context: 'Use before creating tickets to resolve customer email to user_id' and 'Call to populate group dropdown in ticket creation UI'. This guides LLM selection.
• Add enum constraint to article.type in zammad_ticket_create and zammad_ticket_add_article. Schema already has enum=['note','email'], but ensure validation rejects other values with clear error: 'Invalid article type: must be note or email'.
• For zammad_ticket_update, either split into separate tools (update_ticket_state, update_ticket_priority, update_ticket_group, update_ticket_owner) OR add validation that rejects conflicting parameters with guidance: 'Provide either state or state_id, not both. Use state for human-readable names (e.g., "open"), state_id for numeric IDs.'