Related Servers

Domain prefixes (jira_, confluence_, datadog_, git_, snowflake_, transcript_youtube_) cleanly partition the surface, and within each domain the descriptions go out of their way to say when to use a sibling tool instead. A few genuine overlaps remain: jira_edit vs jira_write, jira_transition_list vs jira_transition with list=true, jira_attachment_images vs jira_attachment_download, and jira_comment (action-based list/add) sitting alongside separate edit/delete tools.

The dominant convention is domain_resource_action in snake_case (jira_version_create, confluence_comment_reanchor, datadog_metrics_query), which is applied consistently across the vast majority of the 138 tools. Deviations are minor: verb-first names (ai_chat, git_create_pr, git_staged_commit), verb-less names (confluence_children), action-param tools (jira_comment), and a few one-off prefixes (jev_route, log_search, config_models_show, atlassian_convert).

138 tools is an extreme mismatch for a single MCP server surface; even accepting that omni-dev mirrors a whole CLI across Jira, Confluence, Datadog, git, Snowflake, YouTube and more, this is far past the point where an agent can hold the toolset in context or select reliably. Several tools are near-duplicates that could be collapsed (jira_transition_list, jira_attachment_images, git_lint_commits vs git_check_commits).

Coverage is unusually deep: Jira has full lifecycle CRUD for issues, comments, attachments, worklogs, sprints, versions, components, links, watchers and transitions plus discovery helpers (field list/options, create-meta, link types); Confluence has pages, comments, labels, attachments, restrictions, history, compare and download. Remaining gaps are real but workaroundable: Datadog is entirely read-only (no mute/create downtime/update monitor), and there is no Jira issue-type or Confluence blog-post surface.