ProWoDo

Most tools are clearly distinct by resource type (tasks, projects, sprints, attachments, etc.) and action (list, create, retrieve, update, destroy). A few pairs like create_attachments and request_attachment_upload both create attachments but differ in mechanism—one inline, one via upload—which is explained but could still be initially confusing. Similarly, list_attachments vs list_taskattachments serve different scopes (company/project vs task), clearly described.

Tool names follow a consistent verb_noun pattern: list_<resource>, create_<resource>, retrieve_<resource>, update_<resource>, partial_update_<resource>, destroy_<resource>, and specialized verbs like add_tag_tasks, assign_user_tasks, close_sprints. All in lowercase with underscores, no mixed conventions.

With 85 tools, the server is far beyond the recommended 3-15 tools for typical MCP servers. The large count reflects deep CRUD for many resource types (companies, projects, tasks, sprints, attachments, reminders, comments, dependencies, tags, tickets, resume entries), but it's excessive and could overwhelm agents. Many operations are redundant (full update vs partial update for each resource), contributing to bloat.

The tool surface covers a comprehensive lifecycle for major resources: companies, projects, tasks (with subtasks, ordering, movement), sprints (state transitions), attachments, comments, dependencies, tags, reminders, resume entries, and tickets. Gaps include missing dedicated ticket status update (though task tools can be used), no direct ticket submission creation (only retrieval), and read_attachments cannot handle PDF/Office files (though known gap). Overall, it's quite complete for the domain.