Skip to main content
Glama

omni-dev

MCP Toplist

Crates.io Documentation Build Status License: BSD-3-Clause

An intelligent Git commit message toolkit with AI-powered contextual intelligence. Transform messy commit histories into professional, conventional commit formats with project-aware suggestions.

🎬 See It In Action

asciicast

Watch omni-dev transform messy commits into professional ones with AI-powered analysis

Related MCP server: MCP Atlassian Node Server

30-Second Demo

Transform your commit messages and create professional PRs with AI intelligence:

# Analyze and improve commit messages in your current branch
omni-dev git commit message twiddle 'origin/main..HEAD' --use-context

# Before: "fix stuff", "wip", "update files"
# After:  "feat(auth): implement OAuth2 authentication system"
#         "docs(api): add comprehensive endpoint documentation"
#         "fix(ui): resolve mobile responsive layout issues"

# Create a professional PR with AI-generated description
omni-dev git branch create pr
# 🎉 Generates comprehensive PR with detailed description, testing info, and more

✨ Key Features

  • 🤖 AI-Powered Intelligence: Claude AI analyzes your code changes to suggest meaningful commit messages and PR descriptions

  • 🧠 Contextual Awareness: Understands your project structure, conventions, and work patterns

  • 🔍 Comprehensive Analysis: Deep analysis of commits, branches, and file changes

  • ✏️ Smart Amendments: Safely improve single or multiple commit messages

  • 🚀 PR Creation: Generate professional pull requests with AI-powered descriptions

  • 📦 Automatic Batching: Handles large commit ranges intelligently

  • 🎯 Conventional Commits: Automatic detection and formatting

  • 🌐 Browser Bridge: Drive HTTP requests through an authenticated browser tab without exfiltrating cookies or tokens

  • 🗂️ Worktrees View: One live view of every repo and git worktree open across all your VS Code windows

  • 🛡️ Safety First: Working directory validation, protection against amending commits already in remote main branches, and error recovery

  • ⚡ Fast & Reliable: Built with Rust for memory safety and performance

🚀 Quick Start

Installation

# Install from crates.io
cargo install omni-dev

# Install with Nix
nix profile install github:rust-works/omni-dev

# Install with Nix flakes (development)
nix run github:rust-works/omni-dev

Pre-built binaries are attached to each release. The Linux ones (omni-dev-linux.tar.gz, omni-dev-linux-arm64.tar.gz) are dynamically linked and need glibc 2.35 or newer (Ubuntu 22.04 and Debian 12 qualify). On an older host, such as RHEL 9 or Amazon Linux 2023 (glibc 2.34), they fail in the loader with version `GLIBC_2.xx' not found; build from source with cargo install omni-dev instead. The release workflow fails if a binary needs more than that floor (docs/RELEASE.md).

Next step: see Getting Started — a 10-minute walkthrough from authentication to your first AI-improved commit. (For just the API-key reference, see Authentication.)

Shell Completion

omni-dev completions <shell> prints a completion script to stdout for bash, zsh, fish, powershell, or elvish. The quickest path is bash per-user:

# Add to ~/.bashrc:
eval "$(omni-dev completions bash)"

See docs/shell-completion.md for per-shell install recipes, the $fpath/compinit setup zsh requires, and troubleshooting.

🆚 How omni-dev Compares

omni-dev sits in two adjacent spaces — AI commit-message tooling and Atlassian/dev-workflow MCP servers. The tables below contrast the incumbents on the dimensions a first-time reader is most likely to weigh. In every cell, ✅ means full / native support, ⚠ means partial or available only with caveats, and ❌ means not supported — and omni-dev's own limitations are flagged just as honestly (the ⚠ marks in its own columns).

Beyond these two niches, omni-dev also ships a supervised daemon that hosts a browser bridge (an authenticated proxy that runs requests through a logged-in browser tab for SSO-gated dashboards such as Grafana and Loki), a Snowflake SQL service (one external-browser SSO session reused for concurrent queries), and a worktrees registry (one live view of the repos open across every VS Code window), plus a local append-only request log (omni-dev log). These have no direct incumbent in either table below, so they are called out here rather than scored against tools that don't aim for them.

vs AI commit tools

omni-dev

opencommit

aicommits

Rewrite existing commits in a range

✅ twiddle

❌ pre-commit only

❌ pre-commit only

Parallel batched processing (long ranges)

✅ --concurrency N

❌

❌

AI-written PR descriptions

✅ git branch create pr

⚠ GitHub Action only

❌

Project-context awareness

✅ --use-context

❌

❌

Sandboxed claude-cli backend

✅ ADR-0028

❌

❌

Multi-backend (Anthropic / Bedrock / OpenAI / Ollama)

✅

✅

✅

Conventional Commits

✅

✅

⚠ config

Language / runtime

Rust (static binary)

Node.js

Node.js

vs Atlassian-workflow MCP servers

omni-dev's MCP server also exposes Git tools (commit analysis, twiddling, PR creation), Datadog tools, and an ai_chat proxy — surfaces the Atlassian-focused servers don't aim for. The table below compares only Atlassian capability depth.

omni-dev MCP

sooperset/mcp-atlassian

Atlassian official (Rovo)

Jira REST surface

✅ 36 tools (agile, fields, dev panel, links, watchers, worklogs, versions, changelog)

✅ 49 tools (above + JSM, proforma forms, SLA, batch ops)

⚠ 14 tools (basic CRUD, search, transitions, worklogs only)

Confluence REST surface

✅ 25 tools (history, diff, attachments, labels, spaces, inline + footer comments)

✅ 24 tools (history, diff, attachments, labels; no inline comments / spaces)

⚠ 12 tools (inline + footer comments, spaces; no delete / move / history / diff / attachments / labels)

Lossless JFM ↔ ADF round-trip

✅ full ADF node set (schema v56.1.18) + unsupported-node escape

❌

⚠ raw ADF, model-dependent

Anchored review-comment preservation

✅ annotation marks survive round-trip

❌ anchor stripped, comments orphaned

⚠ ADF carries anchors; model-dependent

Pre-flight ADF schema validation

✅ nesting + arity, before write

❌

❌

Offline JFM ↔ ADF conversion (no creds)

✅ atlassian_convert

❌

❌

Cloud + Server + Data Center

⚠ Cloud verified

✅ Cloud + Server (v6+) + DC (Jira v8.14+)

❌ Cloud only

Auth

⚠ API token only

✅ API token / PAT / OAuth 2.0

✅ OAuth 2.1 / API token

Last verified: 2026-06-23. omni-dev and sooperset rows are live-tested — a tools/list enumeration (omni-dev branch build vs ghcr.io/sooperset/mcp-atlassian:latest) plus a live read→write→read fidelity cycle on a complex page. Atlassian Rovo's server accepts the API token but gates tool execution behind an org-admin grant, so its rows combine Atlassian's Supported tools docs with the ADF-passthrough reasoning (raw ADF can round-trip, but only if the model echoes it faithfully — no deterministic guarantee), not a live run. Refresh quarterly or whenever a release-note search for the comparators flags a relevant change.

📋 Core Commands

🤖 AI-Powered Commit Improvement (twiddle)

The star feature - intelligently improve your commit messages with real-time model information display:

# Improve commits with contextual intelligence
omni-dev git commit message twiddle 'origin/main..HEAD' --use-context

# Process large commit ranges with parallel processing
omni-dev git commit message twiddle 'HEAD~20..HEAD' --concurrency 5

# Save suggestions to file for review
omni-dev git commit message twiddle 'HEAD~5..HEAD' \
  --save-only suggestions.yaml

# Auto-apply improvements without confirmation
omni-dev git commit message twiddle 'HEAD~3..HEAD' --auto-apply

🔍 Analysis Commands

# Analyze commits in detail (YAML output)
omni-dev git commit message view 'HEAD~3..HEAD'

# Analyze current branch vs main
omni-dev git branch info main

# Get comprehensive help
omni-dev help-all

🚀 AI-Powered PR Creation

Create professional pull requests with AI-generated descriptions:

# Generate and create PR with AI-powered description
omni-dev git branch create pr

# Create PR with specific base branch
omni-dev git branch create pr main

# Save PR details to file without creating
omni-dev git branch create pr --save-only pr-description.yaml

# Auto-create without confirmation
omni-dev git branch create pr --auto-apply

📝 Atlassian Integration

Read, write, and manage JIRA issues and Confluence pages from the command line:

# Authenticate with Atlassian Cloud
omni-dev atlassian auth login

# Check authentication status
omni-dev atlassian auth status

# Fetch a JIRA issue as markdown
omni-dev atlassian jira read PROJ-123

# Fetch as raw ADF JSON
omni-dev atlassian jira read PROJ-123 --format adf

# Push markdown changes back to JIRA
omni-dev atlassian jira write PROJ-123 issue.md

# Interactive edit: fetch, edit in $EDITOR, push
omni-dev atlassian jira edit PROJ-123

# Search issues with JQL
omni-dev atlassian jira search --project PROJ --status Open

# Create an issue
omni-dev atlassian jira create issue.md --project PROJ --summary "Fix bug"

# Transition an issue
omni-dev atlassian jira transition PROJ-123 "In Progress"

# Confluence: read, search, create pages
omni-dev atlassian confluence read 12345
omni-dev atlassian confluence search --space ENG --title auth
omni-dev atlassian confluence create page.md --space ENG --title "New Page"

# Convert markdown to ADF JSON (offline)
omni-dev atlassian convert to-adf input.md

Self-hosted PATs use atlassian auth login --auth-mode bearer without email. See PAT authentication and compatibility limits; most service operations still target Cloud APIs.

📊 Datadog Integration (read-only)

Authenticate against the Datadog API and query metrics, monitors, dashboards, logs, events, SLOs, hosts, and downtimes. See the Datadog integration guide for the full subcommand reference, authentication setup, rate-limit behaviour, and troubleshooting.

# Configure Datadog API credentials (prompts for API key, APP key, and site)
omni-dev datadog auth login

# Verify the credentials by calling /api/v1/validate
omni-dev datadog auth status

# Query metrics, monitors, dashboards, logs, and SLOs
omni-dev datadog metrics query --query 'avg:system.cpu.user{*}' --from 15m
omni-dev datadog monitor list --tags env:prod
omni-dev datadog dashboard list
omni-dev datadog logs search --filter 'service:api status:error' --from 1h
omni-dev datadog slo list --tags team:platform

DATADOG_SITE defaults to datadoghq.com. Other regions (datadoghq.eu, us3.datadoghq.com, us5.datadoghq.com, ap1.datadoghq.com, ddog-gov.com) are recognised without warning. Environment variables DATADOG_API_KEY, DATADOG_APP_KEY, DATADOG_SITE override the stored settings. For on-prem or proxied installs, set DATADOG_API_URL to override the site-derived URL.

All Datadog subcommands are also exposed as MCP tools (datadog_*) — see docs/mcp.md. For the full guide covering every family with worked examples, see docs/datadog.md.

📧 Gmail and 📁 Drive (moved to gwi)

These commands, their MCP tools and library modules now live in gwi (Google Workspace Interface), a standalone project (ADR-0095). gwi import copies your existing accounts and settings from ~/.omni-dev; see the user guide.

For one release, omni-dev gmail ... and omni-dev drive ... remain as hidden stubs that accept any arguments and exit non-zero with a message pointing at gwi; the next minor release deletes them.

🎙️ Transcript Fetching

Pull captions and transcripts from external media platforms. YouTube is the first supported source; the CLI namespace and library are designed so additional sources (Vimeo, podcast RSS, generic VTT/SRT URLs) can be added without restructuring. See docs/transcript.md for the full reference and the recipe for adding a new source.

# Fetch captions for a YouTube video as SubRip (default).
omni-dev transcript youtube fetch https://www.youtube.com/watch?v=jNQXAC9IVRw

# WebVTT to a file, falling through to auto-generated captions if needed.
omni-dev transcript youtube fetch jNQXAC9IVRw \
  --format vtt --auto --output me-at-the-zoo.vtt

# Synthesise a translated track when no native French track exists.
omni-dev transcript youtube fetch <url> --lang fr --translate fr

# List available caption tracks (manual + auto-generated).
omni-dev transcript youtube list-langs <url>

# Show video metadata (title, channel, duration, languages).
omni-dev transcript youtube info <url> --output json

--format accepts srt, vtt, txt, or json. Locators may be a watch?v= URL, a youtu.be/ short URL, a /shorts/ or /embed/ URL, or a bare 11-character video ID. Age-gated and login-required videos surface as a typed PlayabilityRefused error carrying YouTube's status code rather than a generic HTTP failure.

🌐 Browser Bridge

Drive HTTP requests through an authenticated browser tab. When you are investigating internal services (Grafana/Loki, internal dashboards, SSO-gated admin panels), the browser already holds sessions — SSO, OAuth, cookies — that are hard to replicate programmatically. The bridge issues requests inside the browser's authenticated context without exfiltrating cookies or tokens (a confused deputy by design). Both planes are authenticated and default-closed; see docs/browser-bridge.md for the full guide and ADR-0036 for the security rationale.

# Start the bridge; it prints the bound ports, a session token, and a JS
# snippet to paste into the DevTools console of the authenticated tab.
omni-dev browser bridge serve

# Drive requests through the tab (token from the bridge's stdout).
export OMNI_BRIDGE_TOKEN=<token printed by the bridge>
omni-dev browser bridge request --url /loki/api/v1/labels

# POST a JSON payload from a file, with a custom header.
omni-dev browser bridge request --url /api/foo --method POST \
  --body @payload.json --header "Accept: application/json"

# Stream a long-lived endpoint (SSE / chunked) instead of buffering.
omni-dev browser bridge request --url /api/events --stream

# Route to a specific tab when several are connected (by id or origin).
omni-dev browser bridge request --url /api/foo --target https://grafana.internal

Supports binary and streaming response bodies, multi-tab routing via X-Omni-Bridge-Target, per-request --credentials and --allow-origin overrides, and a transparent proxy for tools that speak plain HTTP.

🛰️ Daemon

Host long-lived services in one supervised process behind a private per-user Unix-domain control socket. The browser bridge is the first service migrated onto it (Snowflake and the worktrees registry followed), and on macOS an optional menu-bar app gives live control. daemon start installs a launchd LaunchAgent for auto-start at login, and status reports every hosted service. See Running under the daemon and ADR-0039 for the architecture.

# Start the background daemon (installs a launchd LaunchAgent on macOS)
omni-dev daemon start

# Per-service status (add --json for machines)
omni-dev daemon status

# Restart or stop it
omni-dev daemon restart
omni-dev daemon stop

The daemon is Unix-only — its control plane is a Unix-domain socket — while the rest of omni-dev runs everywhere.

❄️ Snowflake

Authenticate a Snowflake session once via external-browser SSO, then run concurrent arbitrary SQL across any account without an SSO popup on every query. The daemon holds the session in memory and multiplexes a bounded pool, so each query can still set its own warehouse/role/database/schema. See docs/snowflake-service.md.

# Run SQL (from an argument or stdin); the first query opens the SSO browser
omni-dev snowflake query "select current_version()"

# Per-query context overrides and JSON output
omni-dev snowflake query "select * from t limit 10" \
  --warehouse WH --role ANALYST --database DB --schema PUBLIC --format json

# Inspect or evict live sessions
omni-dev snowflake sessions
omni-dev snowflake disconnect --account <ACCOUNT> --user <USER>

Account/user/context default from SNOWFLAKE_* env vars then ~/.omni-dev/settings.json — no accounts are hardcoded. Runs on the daemon, so it is Unix-only.

📓 Request Log

Every invocation and the HTTP requests it issues are recorded to a local, append-only log you can search and tail. Best-effort and default-on; no secret is ever written (auth headers are redacted, bodies opt-in). See docs/log.md.

# Recent activity (one line each)
omni-dev log

# Filter by service and status class, or a query expression; follow live
omni-dev log --service jira --status 5xx
omni-dev log --query 'method:POST AND status:4xx' --follow

# Full records as JSON (byte-identical to the on-disk lines)
omni-dev log --format json -n 20

Set OMNI_DEV_LOG_DISABLE=1 to turn it off, or OMNI_DEV_LOG_BODIES=1 / OMNI_DEV_LOG_HEADERS=1 to opt into capturing bodies/headers.

🗂️ Worktrees

See every repo and git worktree open across all your VS Code windows in one live view. A VS Code extension host is sandboxed per window — no extension alone can see a sibling window's folders — so a small first-party companion extension registers each window with the daemon, which aggregates them into a single registry served back to the CLI, tray, and extension UI. The registry is in-memory only; windows that crash without unregistering age out automatically. See docs/worktrees-service.md and ADR-0040.

# One line per open window and its folders (add --json for machines)
omni-dev worktrees list

Runs on the daemon, so it is Unix-only.

🤖 Agent Sessions

Track the Claude Code, Codex and pi.dev sessions running across every terminal and VS Code window, each with a coarse live state (working, idle, or waiting on you). Opt-in hooks, the claude-wrap/codex-wrap wrappers, a pi.dev extension and transcript watchers feed the daemon, which keeps the sessions in memory and serves them to the CLI, the tray, worktrees ui and the VS Code worktrees view. See docs/sessions-service.md.

# Install the Claude Code (and, when present, Codex and pi.dev) hooks
omni-dev sessions install-hooks

# One line per live session
omni-dev sessions list

Runs on the daemon, so it is Unix-only.

🔀 Anthropic Gateway

omni-dev ai gateway serves the Anthropic Messages API in front of a model that speaks the OpenAI protocol (OpenAI, Ollama, LM Studio, vLLM, OpenRouter, Fireworks), so Claude Code and the Anthropic SDKs can use it. It runs standalone or as the daemon's anthropic-gateway service, on 127.0.0.1 behind a token. See docs/anthropic-gateway.md.

OMNI_DEV_GATEWAY_UPSTREAM_URL=http://localhost:11434 OMNI_DEV_GATEWAY_MODEL=qwen3-coder \
  omni-dev ai gateway serve
eval "$(omni-dev ai gateway env)" && claude

⚖️ Jev Judgments

omni-dev ai jev is a client for TypeSafe AI's Jev API, which returns typed probabilistic judgments rather than generated text. Beyond the raw choice/score/noul/ask primitives, route asks which model tier each GitHub issue needs to design, implement and review, and verify-decision checks each claim in a decision comment against the sources it cites. See docs/jev.md.

# Which model tier should handle these issues?
omni-dev ai jev route '#1779' '#1820' -o text

✏️ Manual Amendment

# Apply specific amendments from YAML file
omni-dev git commit message amend amendments.yaml

🧩 Claude Code Slash-Commands

Generate ready-to-use Claude Code slash-command templates into the project's .claude/commands/ directory. Each template is a self-contained workflow that drives a multi-step omni-dev operation from inside a Claude Code session.

# Generate all templates: commit-twiddle, pr-create, pr-update
omni-dev commands generate all

# Or individually
omni-dev commands generate commit-twiddle
omni-dev commands generate pr-create
omni-dev commands generate pr-update

Each subcommand writes .claude/commands/<name>.md. Commit the files to share the workflows with collaborators — Claude Code picks them up automatically, so anyone in the repo can invoke /commit-twiddle, /pr-create, or /pr-update inside a Claude Code session. See the user guide for the full reference.

🗒️ Claude Conversation History

Export your Claude Code chat history to a directory of .jsonl files for behavioural analysis, work-log generation, or downstream tooling. Re-running acts as an idempotent sync: new chats are added, modified chats are overwritten, unchanged chats are skipped.

# Mirror ~/.claude/projects to ./history/ (one .jsonl per chat, grouped by project slug)
omni-dev ai claude history sync --target ./history

# Limit to one project (encoded slug or decoded cwd path)
omni-dev ai claude history sync --target ./history --project /Users/me/work/repo

# Only sessions touched in the last week
omni-dev ai claude history sync --target ./history --since 7d

# Preview without writing, then prune target files for sessions removed upstream
omni-dev ai claude history sync --target ./history --dry-run --prune

# Render LLM-friendly markdown alongside the raw jsonl (one .md per session)
omni-dev ai claude history sync --target ./history --output-format jsonl,markdown

# Markdown only — suitable for piping into a coaching LLM
omni-dev ai claude history sync --target ./history --output-format markdown

The export is a behavioural transcript, not a faithful archive. The top-level session jsonl captures all prompts, responses, thinking blocks, tool calls, and tool-result metadata — the signal needed for analysis. Sub-agent internal turns, large tool-output sidecars, PDF page rasters, and Claude's auto-memory are deliberately excluded; they would bloat any LLM-ingested corpus without adding interaction-pattern signal.

In-progress chats produce a valid jsonl prefix (the source size is captured once at the start of the copy), so you can sync safely while a chat is open. The target layout mirrors the source — <target>/<slug>/<uuid>.jsonl — and source mtime is preserved on each target file so downstream tooling can sort sessions chronologically without parsing every file.

--output-format markdown writes a derived <target>/<slug>/<uuid>.md alongside (or instead of) the jsonl. Each markdown file has YAML frontmatter with session metadata followed by ## User / ## Assistant turns; tool calls render as ### Tool call: <name> blocks, thinking blocks collapse into <details>, and sub-agent (Agent) calls render the prompt argument only.

Agent-to-user interactions are surfaced as first-class structured events so the analyst LLM sees what was actually asked and how the user responded:

  • AskUserQuestion calls render as ### Agent question: <header> with the question text and a bulleted list of options (with descriptions); the paired user reply renders as ## User response.

  • Tool denials show up as **Tool result (<tool>, denied by user):** — detected by the canonical "The user doesn't want to proceed with this tool use" sentinel Claude Code stuffs into the next tool_result.

  • Tool interrupts (escape mid-execution) render as **Tool result (<tool>, interrupted by user):**.

  • Errors (real tool failures, distinct from user denials) keep the error label; successes use ok.

System reminders, attachments, and permission-mode events are included by default — pass --exclude-system to drop them. Markdown idempotency keys off source mtime alone (the rendered length differs from the source length), and --prune only deletes artifacts whose extension matches one of the formats listed in --output-format.

See docs/user-guide.md#ai-claude-history-sync--export-conversation-history for the in-depth reference, and the broader Claude Code Integration section for related commands (ai chat, ai claude skills).

🔌 MCP Server

omni-dev ships an optional Model Context Protocol server so AI assistants (Claude Desktop, Claude Code, the MCP Inspector, custom agents) can call omni-dev over stdio instead of shelling out to the CLI. The server is delivered as a second binary, omni-dev-mcp, gated behind the mcp Cargo feature (see ADR-0021).

Tools cover six domains:

Domain

Examples

Git (5)

git_view_commits, git_branch_info, git_check_commits, git_twiddle_commits, git_create_pr

JIRA (28)

core read/write/search/transition/comment/link/dev/delete; sprints, boards, watchers, worklogs, fields, attachments, projects, changelog

Confluence (13)

read/write/search/create/delete/download/children, comments, labels, user search

Atlassian shared (2)

atlassian_auth_status, atlassian_convert (offline JFM ↔ ADF)

Datadog (14)

metrics, monitors, dashboards, logs, events, SLOs, hosts, downtimes, metrics catalog

AI / Config (5)

ai_chat (one-shot chat), claude_skills_* (sync / clean / status for .claude/skills/ distribution), config_models_show

Resources exposed via URI templates:

URI template

Returns

git://repo/commits/{range}

YAML commit analysis

jira://issue/{key}

JIRA issue as JFM

jira://issue/{key}.adf

JIRA issue body as ADF

confluence://page/{id}

Confluence page as JFM

confluence://page/{id}.adf

Confluence page body as ADF

omni-dev://specs/{name}

Embedded reference specs (e.g. jfm)

See docs/mcp.md for the full tool catalog, resource reference, cross-cutting parameters (output_file, confirm), and troubleshooting.

Install

cargo install omni-dev --features mcp

This adds a second binary, omni-dev-mcp, alongside the regular omni-dev CLI. The default cargo install omni-dev build is unchanged — no MCP dependencies are pulled in unless the mcp feature is enabled.

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json on macOS (or %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "omni-dev": {
      "command": "omni-dev-mcp"
    }
  }
}

Claude Code

Per-project — create .mcp.json at the repo root:

{
  "mcpServers": {
    "omni-dev": {
      "command": "omni-dev-mcp"
    }
  }
}

Or register globally with the Claude Code CLI:

claude mcp add omni-dev omni-dev-mcp

Smoke-test with the MCP Inspector

npx @modelcontextprotocol/inspector omni-dev-mcp

The Inspector opens a browser UI where you can list tools and resources, call any tool interactively, and fetch resources against the current working directory.

Configuration (settings.json)

Three server defaults can be set once in the mcp section of ~/.omni-dev/settings.json instead of per-invocation env vars or flags. All three fields are optional; an absent mcp block leaves the built-in behaviour unchanged.

{
  "mcp": {
    "default_model": "claude-sonnet-4-6",
    "log_level": "info",
    "max_response_bytes": 102400
  }
}

Field

Effect

Fallback

default_model

Model for ai_chat when its model param is omitted

model registry default

log_level

Tracing filter directive for the server

warn (env RUST_LOG overrides)

max_response_bytes

Cap on a tool response before truncation (0 disables)

100 KB

For troubleshooting (stderr logs, RUST_LOG=debug, "failed to open git repository"), see docs/mcp.md#troubleshooting.

⚙️ Configuration Commands

# Show supported AI models and their specifications
omni-dev config models show

# View model information with token limits and capabilities
omni-dev config models show | grep -A5 "claude-opus-4.1"

🧠 Contextual Intelligence

omni-dev understands your project context to provide better suggestions:

Project Configuration

Create .omni-dev/ directory in your repo root:

mkdir .omni-dev

Scope Definitions (.omni-dev/scopes.yaml)

scopes:
  - name: "auth"
    description: "Authentication and authorization systems"
    examples: ["auth: add OAuth2 support", "auth: fix token validation"]
    file_patterns: ["src/auth/**", "auth.rs"]
  
  - name: "api"
    description: "REST API endpoints and handlers"  
    examples: ["api: add user endpoints", "api: improve error responses"]
    file_patterns: ["src/api/**", "handlers/**"]

Commit Guidelines (.omni-dev/commit-guidelines.md)

# Project Commit Guidelines

## Format
- Use conventional commits: `type(scope): description`
- Keep subject line under 50 characters
- Use imperative mood: "Add feature" not "Added feature"

## Our Scopes
- `auth` - Authentication systems
- `api` - REST API changes
- `ui` - Frontend/UI components

🎯 Advanced Features

Intelligent Context Detection

omni-dev automatically detects:

  • Project Conventions: From .omni-dev/, CONTRIBUTING.md

  • Work Patterns: Feature development, bug fixes, documentation, refactoring

  • Branch Context: Extracts work type from branch names (feature/auth-system)

  • File Architecture: Understands UI, API, core logic, configuration changes

  • Change Significance: Adjusts detail level based on impact

Automatic Batching

Large commit ranges are automatically split into manageable batches:

# Processes 50 commits in batches of 4 (default)
omni-dev git commit message twiddle 'HEAD~50..HEAD' --use-context

# Custom concurrency for very large ranges
omni-dev git commit message twiddle 'main..HEAD' --concurrency 2

Command Options

Option

Description

Example

--fresh

Generate fresh messages from the diffs alone (the default; conflicts with --refine)

--fresh

--refine

Refine the existing messages instead of starting fresh (conflicts with --fresh)

--refine

--use-context

Enable contextual intelligence

--use-context

--work-context TEXT

Describe the work being done to steer suggestions

--work-context "feature: user auth"

--branch-context TEXT

Override the context detected from the branch name

--branch-context "bugfix: login flow"

--context-dir PATH

Custom context directory

--context-dir ./config

--model MODEL

Claude API model to use (defaults from settings)

--model claude-sonnet-4-5

--beta-header KEY:VALUE

Beta header for API requests (model-gated)

--beta-header key:value

--concurrency N

Number of parallel commit processors (default: 4)

--concurrency 3

--no-coherence

Skip cross-commit coherence refinement pass

--no-coherence

--no-ai

Skip AI; amend to a deterministic type/scope suggestion, leaving conforming commits untouched

--no-ai

--auto-apply

Apply without confirmation

--auto-apply

--allow-pushed

Allow amending commits already in remote main branches

--allow-pushed

--check

Validate the messages after applying

--check

--save-only FILE

Save to file without applying

--save-only fixes.yaml

--quiet

Only show errors/warnings

--quiet

See the User Guide's Key Options table for the full reference; omni-dev git commit message twiddle --help is the source of truth.

📖 Real-World Examples

Before & After

Before: Messy commit history

e4b2c1a fix stuff
a8d9f3e wip
c7e1b4f update files
9f2a6d8 more changes

After: Professional commit messages

e4b2c1a feat(auth): implement JWT token validation system
a8d9f3e docs(api): add comprehensive OpenAPI documentation
c7e1b4f fix(ui): resolve mobile responsive layout issues
9f2a6d8 refactor(core): optimize database query performance

Workflow Integration

# 1. Work on your feature branch
git checkout -b feature/user-dashboard

# 2. Make commits (don't worry about perfect messages)
git commit -m "wip"
git commit -m "fix stuff"
git commit -m "add more features"

# 3. Before merging, improve all commit messages
omni-dev git commit message twiddle 'main..HEAD' --use-context

# 4. Create professional PR with AI-generated description
omni-dev git branch create pr

# ✅ Professional commit history + comprehensive PR description ready for review

Contributing

We welcome contributions! Please see our Contributing Guidelines for details.

Development Setup

  1. Clone the repository:

    git clone https://github.com/rust-works/omni-dev.git
    cd omni-dev
  2. Install Rust (if you haven't already):

    curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
  3. Build the project:

    cargo build
  4. Run the build script (includes tests, linting, and formatting):

    ./scripts/build.sh

    Or run individual steps:

    cargo test         # Run tests
    cargo clippy       # Run linting
    cargo fmt          # Format code

📚 Documentation

🔧 Requirements

  • Rust: 1.88+ (for installation from source)

  • Claude API Key: Required for AI-powered features

  • AI Model Selection: Optional configuration for specific models

    • View available models: omni-dev config models show

    • Pick per-invocation with --model on an AI command, or configure via OMNI_DEV_MODEL / the per-backend env chain (CLAUDE_MODEL, CLAUDE_CODE_MODEL, ANTHROPIC_MODEL for Claude-family backends; OPENAI_MODEL; OLLAMA_MODEL) or ~/.omni-dev/settings.json

    • Supports standard identifiers and Bedrock-style formats

  • Atlassian Credentials (for JIRA/Confluence features): Instance URL, email, and API token

    • Configure with: omni-dev atlassian auth login

  • Datadog Credentials (for Datadog features): API key, application key, and site

    • Configure with: omni-dev datadog auth login

  • Git: Any modern version

AI backend selection

omni-dev supports five AI backends. The --ai-backend flag — accepted after the AI commands (git commit message twiddle, git commit message check, git commit message staged, git branch create pr, ai chat), or set via OMNI_DEV_AI_BACKEND — selects one decisively — default, claude-cli, openai, ollama, or bedrock:

  • --ai-backend claude-cli — sandboxed claude -p subprocess that reuses your Claude Code session.

  • --ai-backend ollama — local Ollama or LM Studio server.

  • --ai-backend openai — OpenAI Chat Completions API.

  • --ai-backend bedrock — AWS Bedrock.

  • --ai-backend default (or no flag) — direct Anthropic API.

When OMNI_DEV_AI_BACKEND is unset, the legacy USE_OLLAMA=true / USE_OPENAI=true / CLAUDE_CODE_USE_BEDROCK=true variables still select their backends, in that order.

See the AI Backends Guide for required env vars, model selection, the Claude CLI sandbox and its escape hatches (--claude-cli-allow-tools, --claude-cli-allow-mcp), the --claude-cli-max-budget-usd spending cap, and per-backend troubleshooting.

🐛 Debugging

For troubleshooting and detailed logging, use the RUST_LOG environment variable:

# Enable debug logging for omni-dev components
RUST_LOG=omni_dev=debug omni-dev git commit message twiddle ...

# Debug specific modules (e.g., context discovery)  
RUST_LOG=omni_dev::claude::context::discovery=debug omni-dev git commit message twiddle ...

# Show only errors and warnings
RUST_LOG=warn omni-dev git commit message twiddle ...

See Troubleshooting Guide for detailed debugging information.

Changelog

See CHANGELOG.md for a list of changes in each version.

License

This project is licensed under the BSD 3-Clause License - see the LICENSE file for details.

Support

Acknowledgments

  • Thanks to all contributors who help make this project better!

  • Built with ❤️ using Rust

Available Tools

138 tools
ai_chatA

Send a single message to the configured AI (Claude/OpenAI/Ollama/Bedrock) and return its response. Non-streaming, single-turn. Optionally override the model (model) and the system prompt (system_prompt). On missing credentials, returns a tool error containing the same diagnostic the CLI would print. Mirrors omni-dev ai chat in one-shot form — that CLI command is interactive and has no system_prompt flag, so this tool is the only way to set a custom system prompt. Supply the message as message (inline) OR message_path (a filesystem path the server reads) — not both; prefer the path form when the message is already on disk.

Inputs: model, message, message_path, system_prompt.

atlassian_auth_statusA

Report which Atlassian credential scopes have credentials configured. Returns credential presence flags, auth_mode (basic or bearer), and configuration_state only — NEVER includes the email, API token, PAT, or any other secret. The instance URL (non-secret) is returned verbatim. Checks local configuration only; it does NOT call the Atlassian API, read secret files, or run credential helpers to validate the credentials (unlike omni-dev atlassian auth status, which signs in and prints the authenticated user). Takes no arguments. Read-only. Output is YAML.

atlassian_convertA

Convert between JFM (JIRA-Flavoured Markdown) and ADF (Atlassian Document Format) JSON. Bidirectional and fully offline — performs no network I/O and needs no Atlassian credentials. Set direction to "to-adf" to convert JFM markdown into an ADF JSON document (e.g. # Title becomes {"version":1,"type":"doc","content":[...]}), or "from-adf" to render an ADF JSON document back into JFM markdown. Use it to preview or inspect the ADF a JIRA/Confluence write tool would send. Output is the converted document (JSON for to-adf, markdown for from-adf). Mirrors omni-dev atlassian convert to-adf / from-adf.

Inputs: content (required), direction (required), compact, strip_local_ids.

browser_bridge_requestA

Send one HTTP request through a running, authenticated browser-bridge tab and return the buffered response envelope (status, headers, body) as YAML. Mirrors omni-dev browser bridge request. Requires a running bridge (omni-dev browser bridge serve or the daemon's bridge service) and a session token from OMNI_BRIDGE_TOKEN or token_file. NOT read-only — the request runs with the tab's session, so a non-GET method can mutate remote state. url is relative to the tab's page origin unless allow_origin permits a cross-origin target. Streaming responses are not supported here.

Inputs: url (required), body, method, target, +5 more.

claude_skills_cleanA

Remove the skill symlinks under .claude/skills/ and the managed exclude block created by a prior claude_skills_sync — the inverse of that tool. MUTATES THE FILESYSTEM. Real files (non-symlinks) are preserved, never deleted. Operates relative to the server process's cwd. Use claude_skills_status first if you want to see what would be removed. Mirrors omni-dev ai claude skills clean.

Inputs: format, worktrees.

claude_skills_statusA

Report the skill symlinks under .claude/skills/ and the managed exclude-block entries left by prior claude_skills_sync runs. READ-ONLY — changes nothing, so it is the safe way to preview before calling claude_skills_sync or claude_skills_clean. Operates relative to the server process's cwd. Mirrors omni-dev ai claude skills status.

Inputs: format, worktrees.

claude_skills_syncA

Sync Claude Code skills from the current repository (the MCP server's current working directory) into target worktrees. MUTATES THE FILESYSTEM: creates symlinks inside .claude/skills/ (e.g. .claude/skills/my-skill -> ../../../.claude/skills/my-skill) and upserts a managed block in .git/info/exclude. Operates relative to the server process's cwd — not cross-project. Use claude_skills_clean to reverse this and claude_skills_status to inspect the result without changing anything. Mirrors omni-dev ai claude skills sync.

Inputs: format, worktrees.

config_models_showA

Return the embedded models.yaml listing every supported AI model the CLI knows about, with each model's identifier, token limits (input context and max output tokens), and provider. Use this to discover the valid model values accepted by ai_chat and the git tools. Takes no arguments. Read-only. Output is YAML. Mirrors omni-dev config models show --embedded-only (the plain show additionally merges user/project overrides; this tool returns the embedded catalog only).

confluence_attachment_deleteA

Delete a Confluence attachment by ID. Set purge: true to permanently purge instead of moving to trash (requires space admin). Mirrors omni-dev atlassian confluence attachment delete --force.

Inputs: attachment_id (required), purge.

confluence_attachment_downloadA

Download a Confluence attachment by ID to disk. Returns YAML metadata (id, title, media_type, bytes, on-disk path). If output_path is omitted, the file is written to a fresh temp directory whose path is in the result; the assistant can then read it via the filesystem tool. Mirrors omni-dev atlassian confluence attachment download.

Inputs: attachment_id (required), output_path.

confluence_attachment_listA

List attachments on a Confluence page (one page per call). Pass the returned next_cursor back as cursor to fetch the next page. limit defaults to 25. Mirrors omni-dev atlassian confluence attachment list.

Inputs: page_id (required), limit, cursor.

confluence_attachment_updateA

Upload a new binary version of an EXISTING Confluence attachment (by page_id + attachment_id from confluence_attachment_list), bumping its version instead of creating a second attachment. file_path is a path on the MCP server's filesystem (streamed from disk). Optional filename / comment / minor_edit as with upload. Returns YAML describing the updated attachment. Mirrors omni-dev atlassian confluence attachment update.

Inputs: page_id (required), file_path (required), attachment_id (required), comment, +2 more.

confluence_attachment_uploadA

Upload a local file as an attachment to a Confluence page. file_path is a path on the MCP server's filesystem (the file is streamed from disk, never fully buffered). Optional filename overrides the stored name; comment is recorded as a version note; minor_edit (default false) marks the upload as minor. Returns YAML describing the new attachment. Mirrors omni-dev atlassian confluence attachment upload.

Inputs: page_id (required), file_path (required), comment, filename, +1 more.

confluence_childrenA

List children of a Confluence page (pass id, e.g. "12345678"), or top-level pages in a space (pass space, e.g. "ENG") — id and space are mutually exclusive. Supports optional recursion with a max depth, so this is the tool for walking a page hierarchy. To enumerate EVERY page in a space (flat, with status/sort filters and cursor pagination) use confluence_space_pages instead. Mirrors omni-dev atlassian confluence children.

Inputs: id, space, max_depth, recursive.

confluence_comment_addA

Post a markdown comment to a Confluence page as a page-level footer comment. The content is converted to ADF before posting. Supply the body as content (inline) OR content_path (a filesystem path the server reads) — not both. For inline (anchored) comments, use confluence_comment_add_inline. Mirrors omni-dev atlassian confluence comment add.

Inputs: id (required), content, content_path.

confluence_comment_add_inlineA

Post a markdown comment anchored to a text selection on a Confluence page (an inline comment). For a page-level comment not tied to any text, use confluence_comment_add instead. Supply the body as content (inline) OR content_path (a filesystem path the server reads) — not both. anchor_text must match the on-page text exactly; if it appears multiple times, pass match_index (1-based) to pick which occurrence. Errors if the anchor does not match or match_index is out of range. Mirrors omni-dev atlassian confluence comment add-inline.

Inputs: id (required), anchor_text (required), content, match_index, +1 more.

confluence_comment_auditA

Audit every inline comment on a Confluence page for anchor drift. Inline-comment anchors do NOT follow text edits: when the annotated text is rewritten, Confluence leaves the mark on whatever original characters survive, so comments end up torn across fragments, slid onto unrelated text, or dropped. This compares each comment's currently-anchored text against the reviewer's durable original highlight and returns YAML with a per-comment status (ok/torn/mark_lost/drifted), the original vs. current anchored text, and a suggested_new_anchor for drifted comments. Read-only — fix drift with confluence_comment_reanchor. Mirrors omni-dev atlassian confluence comment audit.

Inputs: id (required).

confluence_comment_deleteA

Delete a Confluence comment (by comment_id from confluence_comment_list). kind must be "footer" or "inline". Irreversible: pass confirm: true to authorise — without it the tool refuses and makes no API call. Returns YAML. Mirrors omni-dev atlassian confluence comment delete.

Inputs: kind (required), confirm (required), comment_id (required).

confluence_comment_editA

Edit an existing Confluence comment's body (by comment_id from confluence_comment_list). kind must be "footer" or "inline". The new body replaces the current text; supply it as content (inline) OR content_path (a filesystem path the server reads) — not both. Returns YAML. Mirrors omni-dev atlassian confluence comment edit.

Inputs: kind (required), comment_id (required), content, content_path.

confluence_comment_listA

List comments on a Confluence page (auto-paginated). kind selects "footer", "inline", or "all" (default — both kinds merged and sorted by creation time). limit of 0 returns every comment. Inline comments include their inline_marker_ref and durable inline_original_selection (the reviewer's original highlight); note that inline-comment anchors do NOT follow text edits — use confluence_comment_audit to detect drift and confluence_comment_reanchor to fix it. Comment authors are returned as Atlassian account IDs (e.g. 557058:...) — resolve them to display names with confluence_user_get (pass every distinct author ID in one call). Mirrors omni-dev atlassian confluence comment list.

Inputs: id (required), kind, limit.

confluence_comment_reanchorA

Move an inline comment's anchor to a new run of text in a Confluence page's current ADF, then write the page back in one update — the fix for a comment flagged as drifted/mark_lost by confluence_comment_audit. Pass the inline comment_id and the exact anchor_text to move it to; match_index (1-based) disambiguates when the text occurs more than once. The anchor may span multiple runs (e.g. a phrase split by bold) but not a block boundary. Operates entirely on ADF — it never round-trips through JFM, which would discard the annotation marks. Set dry_run: true to validate and preview the move without writing. Mirrors omni-dev atlassian confluence comment reanchor.

Inputs: id (required), comment_id (required), anchor_text (required), dry_run, +1 more.

confluence_comment_reopenA

Reopen a resolved inline Confluence comment (by comment_id from confluence_comment_list). Inline comments only. Returns YAML. Mirrors omni-dev atlassian confluence comment reopen.

Inputs: comment_id (required).

confluence_comment_repliesA

List the replies (child comments) of a Confluence comment. kind must be "footer" or "inline" — Confluence stores reply chains on kind-specific endpoints, so the caller must commit to one. limit of 0 returns every reply. Mirrors omni-dev atlassian confluence comment replies.

Inputs: kind (required), comment_id (required), limit.

confluence_comment_resolveA

Resolve an inline Confluence comment (by comment_id from confluence_comment_list). Inline comments only. Returns YAML. Mirrors omni-dev atlassian confluence comment resolve.

Inputs: comment_id (required).

confluence_compareA

Compare two versions of a Confluence page. Returns a structurally-aware diff: walks the ADF tree, splits the document into heading-delimited sections, and reports per-block changes rather than character-level deltas over a serialization.

Version refs accept "latest", "previous", "v-N" (e.g. "v-2"), a numeric version, or an ISO 8601 date. previous is relative to to.

Detail levels: summary (counts only), outline (default — per-section change kind + drill-in cursors), full (embeds per-section deltas, budget-truncated).

Mirrors omni-dev atlassian confluence compare run.

Inputs: id (required), to, from, budget, +5 more.

confluence_compare_sectionA

Drill into a section diff using a cursor returned by confluence_compare (outline mode). Stateless: the cursor encodes the page ID and version pair. Output formats: "unified" (default), "side_by_side", "markdown_inline". Mirrors omni-dev atlassian confluence compare section.

Inputs: cursor (required), format.

confluence_copyA

Copy a single Confluence page under a destination parent page (parent_id), giving the copy title. Carries the source page's attachments, labels, and properties (not its restrictions). Single-page copy only. Returns YAML with the new page id. Mirrors omni-dev atlassian confluence copy.

Inputs: title (required), page_id (required), parent_id (required).

confluence_createA

Create a NEW Confluence page (use confluence_write to overwrite an existing page identified by its ID). Builds from explicit fields or from a full JFM document (frontmatter + body, e.g. the output of confluence_read). With a document, space_key/title/parent_id come from the frontmatter and the body becomes the page body — enabling the read → edit → create round-trip. Explicit space_key/title/parent_id override frontmatter and a warning is returned when they do. JFM is GitHub-style markdown, NOT Confluence wiki markup — see resource omni-dev://specs/jfm. The document/content bodies each also accept a filesystem-path form (document_path/content_path) the server reads from disk — prefer it when the body is already on disk, to avoid emitting a large body inline. Set dry_run: true first when uncertain about required fields or formatting — validates the input and returns the request that would be sent (method, path, body) without creating the page. Returns the new page's ID. Mirrors omni-dev atlassian confluence create (and its --dry-run).

Inputs: title, format, content, dry_run, +5 more.

confluence_deleteA

Delete a Confluence page. IRREVERSIBLE. Requires the caller to pass confirm: true to prevent accidental deletions. Set purge: true to permanently purge instead of moving to trash (requires space admin). Mirrors omni-dev atlassian confluence delete --force.

Inputs: id (required), confirm (required), purge.

confluence_downloadA

Recursively download a Confluence page or an entire space into a directory. Either id (root page) or space (space key) must be provided. Set include_attachments: true to also fetch each page's attachment binaries into an attachments/ subdirectory beside its content file. Returns a YAML manifest summary of downloaded pages. To read a single page's body instead (no files written), use confluence_read. Mirrors omni-dev atlassian confluence download.

Inputs: id, space, format, max_depth, +4 more.

confluence_historyA

List version history (metadata only) for a Confluence page. Returns version number, timestamp, author account ID, edit message, and minor-edit flag for each version, newest-first. Resolve those author account IDs to display names with confluence_user_get. Does NOT fetch version bodies — use confluence_read for content. since filters to versions at or after a numeric version ("5") or ISO 8601 date ("2026-01-01T00:00:00Z"). limit defaults to 20; 0 means unlimited. Mirrors omni-dev atlassian confluence history.

Inputs: id (required), limit, since.

confluence_label_addB

Add one or more labels to a Confluence page. Mirrors omni-dev atlassian confluence label add.

Inputs: id (required), labels (required).

confluence_label_listA

List labels on a Confluence page (auto-paginated). limit of 0 returns every label. Mirrors omni-dev atlassian confluence label list.

Inputs: id (required), limit.

confluence_label_removeA

Remove one or more labels from a Confluence page. Destructive operation: callers must explicitly pass confirm: true for the removal to proceed; otherwise the tool refuses with an error. Mirrors omni-dev atlassian confluence label remove.

Inputs: id (required), labels (required), confirm (required).

confluence_moveA

Move or reparent a Confluence page within its current space. position is "append" (default — target becomes new parent), "before", or "after" (sibling reorder relative to target). Same-space only — cross-space moves are not supported. Returns the moved page's metadata as YAML (id, title, parent_id, ancestors). Mirrors omni-dev atlassian confluence move.

Inputs: page_id (required), target_id (required), position.

confluence_readA

Fetch a Confluence page by numeric ID (e.g. "12345678"). Returns JFM markdown by default — AI-friendly GitHub-style markdown, the form to read/edit then feed back to confluence_write/confluence_create. That output carries localId attributes (and inline-comment anchor spans) that anchor inline comments and other stateful nodes — preserve them verbatim when editing so a later confluence_write does not drop those comments. Pass format="adf" for the raw ADF JSON (the on-the-wire document model) only when you need exact node structure. Pass version to read a specific historical version (an immutable snapshot) instead of the current head — useful for seeing what a reviewer was reading when they commented. When output_file is set, the content is written to that path and the tool returns a short YAML summary (path/bytes/format) — useful for large pages. This reads a single page; to fetch a whole page tree or an entire space to disk, use confluence_download instead. NOTE: inline-comment anchors do NOT follow text edits — to detect/repair drifted comments use confluence_comment_audit / confluence_comment_reanchor. Any author/version metadata is returned as Atlassian account IDs — resolve them to display names with confluence_user_get. Mirrors omni-dev atlassian confluence read.

Inputs: id (required), format, version, output_file.

confluence_restriction_getA

Show the read/update restrictions on a Confluence page. Returns the raw restriction JSON as YAML (the model is deeply nested — user/group arrays per operation). Mirrors omni-dev atlassian confluence restriction get.

Inputs: content_id (required).

confluence_restriction_grantA

Grant a user or group a read/update restriction on a Confluence page. operation is "read" or "update"; supply exactly one of account_id or group. Returns YAML {status: ok}. Mirrors omni-dev atlassian confluence restriction grant.

Inputs: operation (required), content_id (required), group, account_id.

confluence_restriction_revokeA

Revoke a user's or group's read/update restriction on a Confluence page. operation is "read" or "update"; supply exactly one of account_id or group. Returns YAML {status: ok}. Mirrors omni-dev atlassian confluence restriction revoke.

Inputs: operation (required), content_id (required), group, account_id.

confluence_space_listA

List Confluence spaces (one page per call). Optional filters: keys (Vec), type (common values: global, personal, collaboration, knowledge_base, onboarding — passed through to the API verbatim, so other template-derived types Atlassian returns are also accepted), status (common values: current, archived). Filters combine as AND. Pass the returned next_cursor back as cursor to fetch the next page. limit defaults to 25. Mirrors omni-dev atlassian confluence space list.

Inputs: keys, type, limit, cursor, +1 more.

confluence_space_pagesA

Enumerate ALL pages within a Confluence space (flat list, one response page per call), e.g. space "ENG". To walk a page hierarchy parent-by-parent instead, use confluence_children. Returns summary records: id, title, status, parentId, authorId, createdAt — no page bodies. Optional filters: status (common values: current, archived, draft, trashed) and sort (common values: id, -id, title, -title, created-date, -created-date, modified-date, -modified-date) — both passed through to the Confluence v2 API verbatim. Pass the returned next_cursor back as cursor to fetch the next page. limit defaults to 25. Mirrors omni-dev atlassian confluence space pages.

Inputs: space (required), sort, limit, cursor, +1 more.

confluence_user_getA

Resolve one or more Atlassian account_ids (as emitted by author fields in confluence_comment_list, confluence_history, confluence_read, etc.) to user records — the reverse of confluence_user_search. Returns YAML with one entry per requested ID: account_id, display_name, email (when accessible), and account_type. Pass every distinct author ID from a batch in one call. Unknown, anonymised, or permission-denied IDs come back as a stub record with an error field (the batch never fails). Mirrors omni-dev atlassian confluence user get.

Inputs: account_ids (required).

confluence_watcher_addA

Add a watcher to a Confluence page (account_id defaults to the authenticated user). Returns YAML {watching: true}. Mirrors omni-dev atlassian confluence watcher add.

Inputs: content_id (required), account_id.

confluence_watcher_removeA

Remove a watcher from a Confluence page (account_id defaults to the authenticated user). Returns YAML {watching: false}. Mirrors omni-dev atlassian confluence watcher remove.

Inputs: content_id (required), account_id.

confluence_watcher_statusA

Report whether a user watches a Confluence page (account_id defaults to the authenticated user). Returns YAML {watching: bool}. Mirrors omni-dev atlassian confluence watcher status.

Inputs: content_id (required), account_id.

confluence_writeA

Overwrite an EXISTING Confluence page's body (identified by id) from JFM markdown (default) or raw ADF JSON. This fully replaces the body — to create a brand-new page instead, use confluence_create. DATA LOSS: inline comments (and task-item state) are anchored to the page through the localId attributes that confluence_read emits; if the body you send omits them, Confluence drops the inline comments tied to those anchors. Edit the JFM returned by confluence_read and keep its localIds intact — do not hand-author a fresh body or send content produced with local IDs stripped (atlassian_convert with strip_local_ids). JFM is GitHub-style markdown, NOT Confluence wiki markup — see resource omni-dev://specs/jfm for syntax. Provide the body as content (inline) OR content_path (a filesystem path the server reads) — not both. Prefer content_path when the body is already on disk: emitting a large body inline is slow, and pages routinely exceed that threshold; the inline form is fine for short bodies. Set dry_run: true first when uncertain about required fields or formatting — validates the input and returns the request that would be sent (method, path, body) without updating the page. Mirrors omni-dev atlassian confluence write --force (and --dry-run).

Inputs: id (required), format, content, dry_run, +1 more.

datadog_auth_statusA

Report which Datadog credential scopes have credentials configured. Returns boolean presence flags only — NEVER includes the API key, application key, or any other secret. The site (non-secret) is returned verbatim. Read-only; takes no parameters. Unlike the CLI omni-dev datadog auth status, this tool only inspects local config presence and does NOT call Datadog's /api/v1/validate endpoint, so it cannot confirm the keys are actually accepted. Output is YAML.

datadog_dashboard_getA

Fetch a single Datadog dashboard by id (string, e.g. abc-def-ghi). Returns the full definition including widgets. Use datadog_dashboard_list to discover ids first. Read-only. Mirrors omni-dev datadog dashboard get. Output is YAML.

Inputs: dashboard_id (required).

datadog_dashboard_listA

List Datadog dashboards (id, title, author). filter_shared (boolean, optional) restricts to shared (true) or non-shared (false) dashboards; omit it for all. Use datadog_dashboard_get to fetch one dashboard's full widget definition by id. Read-only. Mirrors omni-dev datadog dashboard list. Output is YAML.

Inputs: filter_shared.

datadog_downtime_listA

List Datadog scheduled downtimes (monitor muting windows). active_only (boolean, optional, default false) restricts to currently-active downtimes; omit or set false to include past and future ones. Read-only. Mirrors omni-dev datadog downtime list. Output is YAML.

Inputs: active_only.

datadog_events_listA

List Datadog events from the event/alert stream (e.g. deploys, monitor alerts), optionally filtered (e.g. service:api) over a time range (default last 1h). For application log lines use datadog_logs_search instead. limit of 0 (or omitted) auto-paginates across cursor pages up to 10000; any non-zero value caps the total at that count (default 100). from / to accept relative shorthand (15m, 1h), now, RFC 3339, or Unix epoch seconds. Read-only. Mirrors omni-dev datadog events list. Output is YAML.

Inputs: to, from, tags, limit, +2 more.

datadog_hosts_listA

List Datadog reporting hosts, optionally narrowed by a hosts filter (e.g. env:prod) and a from cutoff (Unix epoch seconds). limit of 0 (or omitted) auto-paginates up to 10000. Read-only. Mirrors omni-dev datadog hosts list. Output is YAML.

Inputs: from, limit, filter.

datadog_metrics_catalog_listA

List metrics in the Datadog catalog (/api/v1/metrics). Distinct from datadog_metrics_query: returns metric names (e.g. system.cpu.user) ingested since from, optionally filtered by host — use this to discover what to query, then datadog_metrics_query to fetch the actual timeseries. Read-only. Mirrors omni-dev datadog metrics catalog list. Output is YAML.

Inputs: from, host.

datadog_metrics_queryA

Execute a point-in-time Datadog metrics timeseries query (e.g. avg:system.cpu.user{*} over the last 1h). Returns the actual data points; use datadog_metrics_catalog_list instead when you only need to discover metric names. Read-only. Mirrors omni-dev datadog metrics query. Returns YAML matching the CLI -o yaml output (status, from_date, to_date, series).

Inputs: from (required), query (required), to.

datadog_monitor_getA

Fetch a single Datadog monitor by numeric id (e.g. 12345). Use datadog_monitor_list / datadog_monitor_search to discover ids first. Read-only. Mirrors omni-dev datadog monitor get. Output is YAML.

Inputs: monitor_id (required).

datadog_monitor_listA

List Datadog monitors with optional name / tags filters (e.g. name = "cpu", tags = "team:sre"). Returns full monitor objects. Use datadog_monitor_search for free-text / faceted queries like status:alert; use datadog_monitor_get when you already know the numeric monitor id. limit of 0 (or omitted) auto-paginates up to 10000. Read-only. Mirrors omni-dev datadog monitor list. Output is YAML.

Inputs: name, tags, limit, monitor_tags.

datadog_slo_getA

Fetch a single Datadog SLO by id (string, e.g. abc123def456). Use datadog_slo_list to discover ids first. Read-only. Mirrors omni-dev datadog slo get. Output is YAML.

Inputs: slo_id (required).

datadog_slo_listA

List Datadog Service Level Objectives, optionally filtered by tags, free-text query, explicit ids, or referenced metrics_query. Use datadog_slo_get to fetch one SLO's full definition by id. limit of 0 (or omitted) auto-paginates up to 10000. Read-only. Mirrors omni-dev datadog slo list. Output is YAML.

Inputs: ids, tags, limit, query, +1 more.

git_amend_commitsA

Apply commit message amendments deterministically from an inline YAML document (no AI). This is the apply-messages-from-YAML counterpart to git_twiddle_commits: use git_twiddle_commits with dry_run = true to generate the amendments YAML, then pass it here to apply. Mutating: rewrites commit messages via git commit --amend / interactive rebase. Mirrors omni-dev git commit message amend. Commits already contained in a remote main branch are refused unless allow_pushed = true (rewriting published history).

Inputs: amendments_yaml (required), repo_path, allow_pushed.

git_branch_infoA

Analyze the current branch's commits against a base branch and return repository information as YAML. Use this when you want the diff against main/master (or another base) without computing an explicit range; use git_view_commits instead when you already have a range. Mirrors omni-dev git branch info.

Inputs: branch, repo_path.

git_check_commitsA

Validate commit messages in a range against commit guidelines (read-only — never modifies commits). Use this to report problems; use git_twiddle_commits instead to rewrite the messages. range is required (e.g. HEAD~3..HEAD). Mirrors omni-dev git commit message check. Returns a YAML payload with the full CheckReport, a pass/fail summary, and the exit code the CLI would use (honouring strict).

Inputs: range (required), model, strict, repo_path, +1 more.

git_create_prA

Generate an AI-drafted pull request title and description for the current branch. Mirrors omni-dev git branch create pr in its content-generation phase — this tool returns the proposed PR content as YAML and does NOT push the branch or invoke gh pr create.

Inputs: model, repo_path, base_branch.

git_lint_commitsA

Deterministically validate commit messages against guidelines — no AI, no network, no credentials required (unlike git_check_commits, which calls an AI model). Checks: type/scope format, scope membership in scopes.yaml, subject length, lowercase/no-trailing-period style, blank line after the subject when a body is present, and forbidden footers. Does NOT check type-matches-diff, scope-file-correspondence, or description truthfulness — those need a model and stay in git_check_commits. Set message to lint a single literal message directly (bypassing git entirely), or range to lint every non-merge commit in a range (defaults to commits ahead of the base branch). Set suggest = true to also populate a deterministic corrected-scope suggestion (no AI) for each unknown-scope/missing-scope issue — report-only; apply one via git_amend_commits, or use the CLI's lint --fix to apply directly. Mirrors omni-dev git commit message lint --suggest. Returns a YAML payload with the full CheckReport, a pass/fail summary, and the exit code the CLI would use (honouring strict).

Inputs: range, strict, message, suggest, +2 more.

git_staged_commitA

Generate a Conventional Commits message from the currently staged diff and (by default) commit it via git commit -m. Mirrors omni-dev git commit message staged. Set print_only = true to return the generated message without committing, or no_ai = true to skip the AI backend entirely and return a deterministic type(scope): skeleton instead (no AI, no network, no credentials required; never commits).

Inputs: model, no_ai, repo_path, print_only.

git_twiddle_commitsA

Generate improved commit messages for a range (e.g. HEAD~3..HEAD) and (by default) apply them. Mutating: rewrites commit messages unless dry_run = true. Use this to fix messages; use git_check_commits instead to only report problems without modifying anything. Mirrors omni-dev git commit message twiddle --auto-apply. Set dry_run = true to return the proposed amendments as YAML without applying them. The editor is never started from this tool. Commits already contained in a remote main branch are refused (rewriting published history); overriding requires a human running omni-dev git commit message amend --allow-pushed from the CLI.

Inputs: model, range, dry_run, repo_path.

git_view_commitsA

Analyze commits in a range and return repository information as YAML. Use this when you have an explicit commit range (e.g. HEAD~3..HEAD); use git_branch_info instead to analyze the current branch against a base branch without computing the range yourself. Mirrors omni-dev git commit message view.

Inputs: range, repo_path.

jev_routeA

Route GitHub issues to model classes for design, implementation and review. Mirrors ai jev route; returns models, usage, probabilities, close calls, dependencies and cache metadata as JSON/YAML. Supply issues OR all_open. Draft comments are local previews and never posted. Requires gh authentication and configured Jev credentials. Closed issues are refused by default. Partial issue failures retain the report with isError=true; authentication failures abort.

Inputs: repo, issues, output, ladders, +11 more.

jev_verify_decisionA

Verify a GitHub decision comment against its cited issues/PRs using the configured AI splitter and Jev. Mirrors ai jev verify-decision; latest selects the most recent comment with citations. Returns accepted, rejected or needs_review plus statements, coverage, models, usage and cache metadata as JSON/YAML. These verdicts are successful tool results. Low coverage alone requires review. Checks source fidelity, not whether the decision is correct. Requires gh, Jev and AI backend credentials; backend selection is server configuration, model overrides are request-local.

Inputs: issue (required), repo, model, output, +7 more.

jira_attachment_deleteA

Delete a JIRA attachment by ID. DESTRUCTIVE AND IRREVERSIBLE (JIRA has no trash). You must explicitly pass confirm: true for the deletion to proceed; otherwise the tool returns an error without contacting the API. Returns YAML {status: ok} on success. Mirrors omni-dev atlassian jira attachment delete --force.

Inputs: confirm (required), attachment_id (required).

jira_attachment_downloadA

Download attachments on a JIRA issue to disk. Returns YAML metadata (id, filename, mime_type, size, on-disk path) for each downloaded file. If output_dir is omitted, files are written to a fresh temp directory whose path is in the result; the assistant can then read them via the filesystem tool. Mirrors omni-dev atlassian jira attachment download.

Inputs: key (required), filter, output_dir.

jira_attachment_imagesA

Download image attachments (PNG, JPEG, GIF, SVG, WebP) on a JIRA issue to disk. Returns YAML metadata for each downloaded image. If output_dir is omitted, files are written to a fresh temp directory. Mirrors omni-dev atlassian jira attachment images.

Inputs: key (required), output_dir.

jira_attachment_uploadA

Upload one or more local files as attachments to a JIRA issue. Provide file_paths as absolute paths on the MCP server's filesystem; each is streamed from disk and rides a single multipart request. Returns YAML metadata (id, filename, mime_type, size, content_url) for each created attachment. Mirrors omni-dev atlassian jira attachment upload.

Inputs: key (required), file_paths (required).

jira_board_issuesA

List issues on a JIRA agile board (every issue on the board, across its backlog and all its sprints). Accepts an optional JQL filter. Returns YAML. To scope to a single sprint's issues instead, use jira_sprint_issues. Mirrors omni-dev atlassian jira board issues.

Inputs: board_id (required), jql, limit.

jira_board_listA

List JIRA agile boards, optionally filtered by project key and/or board type (scrum/kanban). Returns YAML. Mirrors omni-dev atlassian jira board list.

Inputs: limit, project, board_type.

jira_bulk_createA

Bulk-create JIRA issues and (optionally) wire dependency links between them in one call — built for epic decomposition. issues are created in order and each may carry a local alias. links are created afterward; each inward/outward is resolved alias-first (to the freshly-minted key) else treated as an existing issue key, so you can link issues this same call just created. Default is continue-on-error: every record is attempted and a YAML report lists per-issue {alias, ok, key, self_url | error}, per-link {ok | error}, and a summary. Set fail_fast to stop at the first failure. NOTE: JIRA has no transaction — nothing is rolled back; the report always shows exactly what succeeded so you can retry only the remainder. To link existing issues only, pass an empty issues array and reference real keys in links.

Inputs: issues (required), links, fail_fast.

jira_changelogA

Get the change history for a JIRA issue. Returns YAML with one entry per change (author, timestamp, items). The author is an Atlassian account ID — resolve it to a display name with jira_user_get. Mirrors omni-dev atlassian jira changelog.

Inputs: key (required), limit.

jira_commentA

Manage JIRA issue comments on key (e.g. PROJ-123). action = "list" returns comments as YAML; action = "add" posts the given body (JFM markdown — GitHub-style, see resource omni-dev://specs/jfm). Supply the body as body (inline) OR body_path (a filesystem path the server reads) — not both. Listed comment authors are Atlassian account IDs — resolve them to display names with jira_user_get. To change the text of an existing comment use jira_comment_edit (it needs the comment id from the list output).

Inputs: key (required), action (required), body, limit, +1 more.

jira_comment_deleteA

Delete a JIRA comment (identified by key + comment_id; get the id from jira_comment with action = "list"). Irreversible: pass confirm: true to authorise — without it the tool refuses and makes no API call. To change a comment's text instead of removing it use jira_comment_edit. Mirrors omni-dev atlassian jira comment delete. Returns a short status line.

Inputs: key (required), comment_id (required), confirm.

jira_comment_editA

Edit an existing JIRA comment (identified by key + comment_id; get the id from jira_comment with action = "list"). To add a new comment or list comments use jira_comment instead. body is JFM markdown (see resource omni-dev://specs/jfm) and replaces the current comment text; supply it as body (inline) OR body_path (a filesystem path the server reads) — not both. Optional visibility = {type: "group"|"role", value: <name>} updates the restriction. JIRA enforces stricter permissions on edit than on add (often only the original author can edit) — when JIRA refuses, its error message is surfaced verbatim. Returns the updated comment metadata as YAML.

Inputs: key (required), comment_id (required), body, body_path, +1 more.

jira_component_createA

Create a JIRA project component (project, name, optional description). Returns YAML for the created component. Mirrors omni-dev atlassian jira component create.

Inputs: name (required), project (required), description.

jira_component_deleteA

Delete a JIRA component (by component_id from jira_component_list). Optionally reassign referencing issues via move_issues_to. Irreversible: pass confirm: true to authorise — without it the tool refuses and makes no API call. Returns YAML {status: ok}. Mirrors omni-dev atlassian jira component delete.

Inputs: component_id (required), confirm, move_issues_to.

jira_component_listA

List a JIRA project's components. Returns YAML. Mirrors omni-dev atlassian jira component list.

Inputs: project (required).

jira_component_updateA

Update a JIRA component's name and/or description (by component_id from jira_component_list; supply at least one field). Returns YAML {status: ok}. Mirrors omni-dev atlassian jira component update.

Inputs: component_id (required), name, description.

jira_createA

Create a new JIRA issue, from explicit fields or from a full JFM document (frontmatter + body, e.g. the output of jira_read). With a document, project/summary/issue_type, labels and custom fields come from the frontmatter (project is derived from key: when no project: is set) and the body becomes the description — enabling the read → edit → create round-trip. Explicit project/summary/issue_type override frontmatter and a warning is returned when they do. Without a document, custom_fields is an optional map of field name or canonical id (e.g. {"Story Points": 8} or {"Planned / Unplanned Work": "Unplanned"}) to value, resolved against the create screen and shaped for the API — use it to satisfy fields a project requires at create time (otherwise JIRA returns HTTP 400). The document/description bodies each also accept a filesystem-path form (document_path/description_path) the server reads from disk — prefer it when the body is already on disk, to avoid emitting a large body inline. Set dry_run: true first when uncertain about required fields or formatting — validates and resolves the input and returns the request that would be sent (method, path, body) without creating the issue (mirrors the CLI's omni-dev atlassian jira create --dry-run). Returns the new issue key and self URL as YAML. Creates a single issue; to create several issues at once (and optionally link them, e.g. epic decomposition) use jira_bulk_create.

Inputs: dry_run, project, summary, document, +5 more.

jira_deleteA

Delete a JIRA issue. DESTRUCTIVE AND IRREVERSIBLE. You must explicitly pass confirm: true for the deletion to proceed; otherwise the tool returns an error without contacting the API. Returns YAML {status: ok} on success. Mirrors omni-dev atlassian jira delete.

Inputs: key (required), confirm (required).

jira_devA

Fetch development status for a JIRA issue by key (e.g. PROJ-123): linked pull requests, branches, and repositories as YAML. Read-only.

Inputs: key (required).

jira_editA

Set arbitrary fields on an existing JIRA issue by field display name or canonical id — labels, selects, story points, dates, rich-text custom fields (e.g. Acceptance Criteria), parent, and other editable fields. Names are resolved against the issue's edit screen and values coerced to the API shape, so pass natural values: {"Labels": ["a", "b"], "Story Points": 8, "Acceptance Criteria": "- one\n- two"}. String values for rich-text fields are JFM markdown auto-converted to ADF ("" clears the field); pass a raw ADF object ({"type": "doc", ...}) to bypass conversion. Complements jira_write (description body, assignee/reporter, raw-id fields); to change workflow status use jira_transition; for hierarchy jira_link_parent remains the canonical surface. Set dry_run: true to preview the request (method, path, body) without updating. Returns {status: ok, key, updated_fields} as YAML. Mirrors the CLI's omni-dev atlassian jira write --set-field.

Inputs: key (required), fields (required), dry_run.

jira_field_listA

List JIRA field definitions, optionally filtered by name substring. Returns YAML. Mirrors omni-dev atlassian jira field list. The schema_type is "richtext" for ADF-required custom fields (e.g. Acceptance Criteria); schema_custom, when present, holds the raw plugin URI (e.g. com.atlassian.jira.plugin.system.customfieldtypes:textarea).

Inputs: search.

jira_field_optionsA

List allowed option values for a JIRA custom field. If context_id is omitted, the first context for the field is auto-discovered. Returns YAML. Mirrors omni-dev atlassian jira field options.

Inputs: field_id (required), context_id.

jira_label_addA

Add one or more labels to a JIRA issue incrementally (leaves the issue's other labels untouched, unlike jira_edit with a full labels array). JIRA labels cannot contain spaces. Returns YAML {status: ok}. Mirrors omni-dev atlassian jira label add.

Inputs: key (required), labels (required).

jira_label_removeA

Remove one or more labels from a JIRA issue incrementally (leaves the issue's other labels untouched). Returns YAML {status: ok}. Mirrors omni-dev atlassian jira label remove.

Inputs: key (required), labels (required).

jira_project_create_metaA

Introspect which fields a JIRA issue type needs: for each field on the create screen, returns required, schema_type, allowed values (resolving option/select/cascading-select), and any default. Collapses the create→HTTP 400→jira_field_list→jira_field_options recovery loop into a single pre-flight call. Returns YAML. Mirrors omni-dev atlassian jira project create-meta.

Inputs: project (required), issue_type (required).

jira_project_listA

List JIRA projects. Returns YAML. Mirrors omni-dev atlassian jira project list.

Inputs: limit.

jira_readA

Fetch a JIRA issue by key (e.g. PROJ-123). Returns JFM markdown (default, AI-friendly GitHub-style markdown — see resource omni-dev://specs/jfm) or the raw ADF description JSON when format = "adf". When output_file is set, the content is written to that path and the tool returns a short YAML summary (path/bytes/format) — useful for large issues. Assignee/reporter and other people fields are Atlassian account IDs — resolve them to display names with jira_user_get.

Inputs: key (required), format, output_file.

jira_sprint_addB

Add one or more issues to a JIRA sprint by issue key. Returns YAML {status: ok} on success. Mirrors omni-dev atlassian jira sprint add.

Inputs: sprint_id (required), issue_keys (required).

jira_sprint_createA

Create a new sprint on a JIRA agile board. Returns YAML for the created sprint. Mirrors omni-dev atlassian jira sprint create.

Inputs: name (required), board_id (required), goal, end_date, +1 more.

jira_sprint_deleteA

Delete a JIRA sprint (by sprint_id). Irreversible: pass confirm: true to authorise — without it the tool refuses and makes no API call. Returns YAML {status: ok}. Mirrors omni-dev atlassian jira sprint delete.

Inputs: sprint_id (required), confirm.

jira_sprint_issuesA

List issues in one JIRA sprint (get sprint IDs from jira_sprint_list). Accepts an optional JQL filter. Returns YAML. For every issue on a board regardless of sprint, use jira_board_issues instead. Mirrors omni-dev atlassian jira sprint issues.

Inputs: sprint_id (required), jql, limit.

jira_sprint_listA

List sprints on an agile board, optionally filtered by state (active/future/closed). Returns YAML. Mirrors omni-dev atlassian jira sprint list.

Inputs: board_id (required), limit, state.

jira_sprint_updateA

Update sprint name, state (future/active/closed), dates, or goal. Returns YAML {status: ok}. Mirrors omni-dev atlassian jira sprint update.

Inputs: sprint_id (required), goal, name, state, +2 more.

jira_transitionA

Transition a JIRA issue to a new workflow status. Most common usage: pass the transition name in transition, e.g. transition: "In Progress". The numeric id also works, e.g. transition: "31". Names are matched case-insensitively. If unsure which transitions are valid from the issue's current status, call this tool first with list = true (or omit transition) to get the available {id, name} pairs as YAML, then call again with one of those names. For transitions whose screen requires input, pass resolution (e.g. "Fixed") and/or custom_fields (a name→value map). Optionally pass comment (JFM markdown): it rides in the transition when the screen accepts a comment (satisfying a mandatory-comment screen), otherwise it is posted separately after the transition succeeds.

Inputs: key (required), list, comment, resolution, +2 more.

jira_transition_listA

List the workflow transitions available from a JIRA issue's current status. Returns YAML with {id, name, to_status, has_screen} for each transition. Faster and lighter than jira_read when you only need the transition ids and names to feed into jira_transition. Equivalent to jira_transition with list = true, but exposed as a single-purpose tool for discoverability.

Inputs: key (required).

jira_user_getA

Resolve one or more Atlassian account_ids (as emitted by author fields in jira_comment, jira_read, jira_changelog, etc.) to user records — the reverse of jira_user_search. Returns YAML with one entry per requested ID: account_id, display_name, email_address (often redacted by GDPR), active, and account_type. Pass every distinct author ID from a batch in one call. Unknown, anonymised, or permission-denied IDs come back as a stub record with an error field (the batch never fails); deactivated accounts resolve normally with active: false. Mirrors omni-dev atlassian jira user get.

Inputs: account_ids (required).

jira_version_archiveB

Archive a JIRA project version (by version_id from jira_version_list). Returns YAML {status: ok}. Mirrors omni-dev atlassian jira version archive.

Inputs: version_id (required).

jira_version_createA

Create a new version in a JIRA project. Dates must be YYYY-MM-DD and are validated client-side. Returns YAML for the created version. Mirrors omni-dev atlassian jira version create.

Inputs: name (required), project (required), archived, released, +3 more.

jira_version_deleteA

Delete a JIRA project version (by version_id from jira_version_list). Optionally reassign affected issues first via move_fix_issues_to / move_affected_issues_to (target version ids). Irreversible: pass confirm: true to authorise — without it the tool refuses and makes no API call. Returns YAML {status: ok}. Mirrors omni-dev atlassian jira version delete.

Inputs: version_id (required), confirm, move_fix_issues_to, move_affected_issues_to.

jira_version_listA

List versions for a JIRA project, optionally filtered by released and archived flags. Returns YAML. Mirrors omni-dev atlassian jira version list.

Inputs: project (required), archived, released.

jira_version_releaseA

Mark a JIRA project version as released (by version_id from jira_version_list). Optional release_date (YYYY-MM-DD, validated client-side). Returns YAML {status: ok}. Mirrors omni-dev atlassian jira version release.

Inputs: version_id (required), release_date.

jira_version_renameA

Rename a JIRA project version (by version_id from jira_version_list), optionally updating its description. Returns YAML {status: ok}. Mirrors omni-dev atlassian jira version rename.

Inputs: name (required), version_id (required), description.

jira_watcher_addA

Add a user (by Atlassian accountId, not a name or email — resolve one with jira_user_search) as a watcher on a JIRA issue. Returns YAML {status: ok}. Mirrors omni-dev atlassian jira watcher add.

Inputs: key (required), account_id (required).

jira_watcher_listA

List watchers on a JIRA issue. Returns YAML with watch_count and an array of watcher accounts. Mirrors omni-dev atlassian jira watcher list.

Inputs: key (required).

jira_watcher_removeA

Remove a user (by Atlassian accountId, not a name or email — resolve one with jira_user_search) from the watchers of a JIRA issue. Destructive operation: callers must explicitly pass confirm: true for the removal to proceed; otherwise the tool refuses with an error. Returns YAML {status: ok}. Mirrors omni-dev atlassian jira watcher remove.

Inputs: key (required), confirm (required), account_id (required).

jira_worklog_addB

Log time on a JIRA issue. time_spent accepts JIRA's duration format (e.g., 1h 30m, 2d). Returns YAML {status: ok}. Mirrors omni-dev atlassian jira worklog add.

Inputs: key (required), time_spent (required), comment, started.

jira_worklog_deleteA

Delete a JIRA worklog (by key + worklog_id; get the id from jira_worklog_list). Irreversible: pass confirm: true to authorise — without it the tool refuses and makes no API call. Returns YAML {status: ok}. Mirrors omni-dev atlassian jira worklog delete.

Inputs: key (required), worklog_id (required), confirm.

jira_worklog_listA

List worklog entries on a JIRA issue. Returns YAML. Mirrors omni-dev atlassian jira worklog list.

Inputs: key (required), limit.

jira_worklog_updateA

Edit an existing JIRA worklog (by key + worklog_id; get the id from jira_worklog_list). Supply at least one of time_spent (JIRA duration, e.g. 1h 30m), started (ISO 8601), or comment; omitted fields keep their current value. Returns YAML {status: ok}. Mirrors omni-dev atlassian jira worklog edit.

Inputs: key (required), worklog_id (required), comment, started, +1 more.

jira_writeA

Update a JIRA issue by key (e.g. PROJ-123). content updates the description (JFM markdown by default, or raw ADF JSON when format = "adf"); omit it to leave the description unchanged. Supply the description as content (inline) OR content_path (a filesystem path the server reads) — not both; prefer the path form when the body is already on disk. JFM is GitHub-style markdown — see resource omni-dev://specs/jfm for syntax. To set the parent for hierarchy (Epic → Story, Story → Sub-task) use the jira_link_parent tool — the canonical hierarchy surface. assignee/reporter accept an accountId (use the empty string "" to clear, "-1" for JIRA automatic assignment); call jira_user_search first if you only have a name or email. fields is an escape hatch — a map of canonical JIRA field id to its API JSON value (e.g. {"priority": {"name": "High"}}) — for fields without a typed parameter. String values targeting rich-text custom fields (e.g. Acceptance Criteria) are auto-converted from JFM to ADF; pass the empty string "" to clear such a field. Pass a JSON object value to bypass conversion (raw ADF). To set fields by display name with automatic value coercion, prefer the jira_edit tool. At least one of content, assignee, reporter, or fields must be supplied. Set dry_run: true first when uncertain about required fields or formatting — validates the input and returns the request that would be sent (method, path, body) without updating the issue. Mirrors the CLI's omni-dev atlassian jira write --dry-run.

Inputs: key (required), fields, format, content, +4 more.

snowflake_disconnectA

Disconnect (evict) one multiplexed Snowflake session identified by its account and user. Mirrors omni-dev snowflake disconnect. Returns whether a session was actually evicted. Requires a running daemon.

Inputs: user (required), account (required), socket.

snowflake_queryA

Run SQL against Snowflake and return the result set(s) as YAML. Mirrors omni-dev snowflake query. Multi-statement scripts (;-separated) are supported: the reply is a statements array with one {columns, rows} result set per statement. The query runs through the omni-dev daemon, which multiplexes authenticated (account, user) sessions — so the daemon must be running (omni-dev daemon start). First-time use of an (account, user) authenticates via external-browser SSO on the daemon host (a browser may open there). account/user default to SNOWFLAKE_ACCOUNT/SNOWFLAKE_USER (and settings.json) when omitted; warehouse/role/database/schema are optional per-query context.

Inputs: sql (required), role, user, schema, +4 more.

snowflake_sessionsA

List the omni-dev daemon's active multiplexed Snowflake sessions as YAML (per-pool account/user, live/max sessions, query counts). Read-only. Mirrors omni-dev snowflake sessions. Requires a running daemon.

Inputs: socket.

transcript_youtube_fetchA

Fetch the transcript for a YouTube video and return it rendered as text. Read-only. Mirrors omni-dev transcript youtube fetch. format is txt (default, one cue per line), srt, vtt, or json. lang defaults to en (prefix fallback: en matches en-US). Set auto = true to allow auto-generated (ASR) captions when no manual track matches; set translate to request a machine-translated track in that language.

Inputs: url (required), auto, lang, format, +1 more.

transcript_youtube_infoA

Fetch top-level metadata about a YouTube video (title, author, duration, available caption tracks) as YAML. Read-only. Mirrors omni-dev transcript youtube info.

Inputs: url (required).

transcript_youtube_list_langsA

List the caption tracks available on a YouTube video (code, name, and whether each is manual, auto-generated, or translated) as YAML. Read-only. Mirrors omni-dev transcript youtube list-langs.

Inputs: url (required).

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.6/5.0

    Scored across 138 tools

    Disambiguation4/5

    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.

    Naming Consistency4/5

    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).

    Tool Count1/5

    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).

    Completeness4/5

    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.

    Maintenance

    ActivityNo data
    ResponsivenessSyncing

    Related MCP Connectors

    Related MCP Servers