Four tools with complete input schemas and descriptions. Naming is clear and action-oriented (ticket, ticket_link, ticket_board, ticket_search). Descriptions are adequate (50-150 chars) but lack LLM-optimized guidance on WHEN to use each tool vs. alternatives. Parameters are well-typed with enums for constrained inputs (action, view, fields). Critical gap: no documented output schemas, LLMs cannot infer what fields to expect from responses, forcing them to guess at downstream chaining. Error handling is present in code (mcp_error, not_found_error, recoverable_error) but not surfaced in tool descriptions. Batch operations (batch_archive, batch_move, batch_close) lack confirmation/dry-run guidance despite being destructive. ticket tool is overloaded with 16 actions, violates single-responsibility principle.

• Document output schemas for all four tools. Specify the structure of ticket objects (id, title, status, assignee, etc.), link objects, board views, and search results. Include which fields are always present vs. optional.
• Split ticket tool into focused single-action tools: create_ticket, get_ticket, list_tickets, update_ticket, move_ticket, close_ticket, append_note, archive_ticket, unarchive_ticket, claim_ticket, release_ticket, claim_next_ticket. This matches LLM mental models and reduces reasoning overhead.
• Add confirmation/dry-run guidance to batch operations. Update descriptions: 'Set confirm=true to execute; omit or set false to preview changes.' Provide example responses showing what preview mode returns.
• Enhance tool descriptions with WHEN guidance. E.g., 'Use ticket_search for full-text queries across title/description; use ticket list with filters for status/type/assignee queries.' Add prerequisites: 'Requires project name, call list_projects first if unknown.'
• Document error responses in tool descriptions. E.g., 'Returns 404 if ticket not found, try ticket_search to verify the ticket exists. Returns 403 if user lacks permission, check project role.' This guides LLM recovery.