Three tools with complete schemas and descriptions, but significant gaps in parameter clarity, error handling, and output documentation. All tools are read-only (good security posture). Schemas use Zod with descriptions, but parameter relationships are underdocumented. No output schemas documented. Error handling is minimal, API errors are passed through without recovery guidance. Tool names are clear (tickets, ticket_details, ticket_stats) but descriptions could be more concise and action-oriented.

• Document output schemas for all three tools. Example: 'Returns {tickets: [{key, type, status, created, updated}], total, page, pageSize}' so LLMs know what fields to extract.
• Convert 'include' parameter in tickets to an enum: ['fields', 'snapshots', 'texts', 'attachments'] instead of free-form comma-separated string.
• Add explicit validation and error recovery: catch API errors and return structured guidance. E.g., 'Ticket not found. Try searching with list action and a filter.' instead of raw 404.
• Clarify ticket_stats parameter dependencies: mark 'from' and 'to' as required (not optional) for all actions except those that don't need date ranges. Document the 90-day max range constraint in parameter descriptions.
• Add per-tool descriptions of what each action returns and when to use it. E.g., 'tickets/list: Returns paginated ticket summaries (key, type, status). Use to search and filter. Supports page/pageSize pagination.'