WithNettle

Most tools target clearly distinct resources or actions (ancestors, children, attachments, image, move, comment, search). The main ambiguity is between get_ticket (one ticket by ID) and get_ticket_content (full content with description/comments/hierarchy), plus get_ticket vs resolve_ticket_reference, which descriptions partially but not fully clarify. Overall an agent can usually pick correctly, with a couple of easily confused pairs.

All 15 tools follow a consistent snake_case verb_noun pattern (create_ticket, get_ticket, update_ticket, move_ticket, search_tickets, list_projects, add_ticket_comment). The get_ticket_* family is a coherent, predictable namespace. No mixing of conventions.

15 tools sits at the top of the well-scoped 3-15 range and each tool maps to a real operation in the ticket-hierarchy domain. The multiple get_ticket_* variants each earn their place as distinct sub-reads rather than padding.

Core lifecycle is covered: create, read (several granular reads), update, move, search, comment, projects, and workflow statuses. Gaps are minor but real: no delete/archive for tickets and no add/remove attachment or comment-editing operations, though agents can work around these.