omni-dev
The omni-dev MCP server is an AI-powered developer toolkit providing Git workflow automation, Atlassian (JIRA/Confluence) management, Datadog observability, and AI chat — all via the Model Context Protocol.
AI Chat & Configuration
Send one-shot messages to AI backends (Claude, OpenAI, Ollama, Bedrock) with optional model/system prompt overrides
List supported AI models with token limits and provider info
Git Workflow Automation
View and analyze commits in a range or against a base branch
Validate commit messages against guidelines
Rewrite/improve commit messages with AI (with dry-run support)
Generate AI-drafted PR titles and descriptions
Commit staged changes with an AI-generated Conventional Commits message
JIRA Issue Management
Full lifecycle: create, read, update, delete, search (JQL), and bulk-create issues
Manage comments, attachments, worklogs, watchers, links, versions, sprints, and boards
Transition issues through workflow statuses; view changelogs and development status
List fields, projects, field options, and search users
Confluence Page Management
Create, read, write, delete, and move pages; download entire page trees or spaces
View version history and compare versions (summary, outline, or full diff)
Manage comments (footer/inline/replies), labels, and attachments
Search pages (CQL), list spaces, enumerate pages, and list children with optional recursion
Datadog Monitoring (Read-Only)
Query metric timeseries and list metric names
List/get monitors, dashboards, SLOs, hosts, scheduled downtimes
Search logs and list events from the alert stream
Atlassian Utilities
Offline bidirectional conversion between JIRA-Flavored Markdown (JFM) and Atlassian Document Format (ADF) JSON
Check Atlassian and Datadog authentication status without exposing secrets
Claude Skills Sync
Manage Claude Code skill symlinks (sync, clean, inspect) across Git worktrees
Read, write, and manage JIRA issues and Confluence pages, including authentication, search, creation, editing, and transitions.
Read, search, and create Confluence pages with markdown support.
Query metrics, monitors, dashboards, logs, events, SLOs, hosts, and downtimes from Datadog (read-only).
Manage JIRA issues: read, search, create, update, transition issues, and convert markdown to ADF.
Fetch captions and transcripts from YouTube videos in formats like SRT, VTT, and JSON.
omni-dev
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

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-devPre-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 | |||
Rewrite existing commits in a range | ✅ | ❌ pre-commit only | ❌ pre-commit only |
Parallel batched processing (long ranges) | ✅ | ❌ | ❌ |
AI-written PR descriptions | ✅ | ⚠ GitHub Action only | ❌ |
Project-context awareness | ✅ | ❌ | ❌ |
Sandboxed | ✅ 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 | |||
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) | ✅ | ❌ | ❌ |
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.mdSelf-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:platformDATADOG_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.internalSupports 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 stopThe 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 20Set 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 listRuns 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 listRuns 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-updateEach 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 markdownThe 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:
AskUserQuestioncalls 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 nexttool_result.Tool interrupts (escape mid-execution) render as
**Tool result (<tool>, interrupted by user):**.Errors (real tool failures, distinct from user denials) keep the
errorlabel; successes useok.
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) |
|
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) |
|
Datadog (14) | metrics, monitors, dashboards, logs, events, SLOs, hosts, downtimes, metrics catalog |
AI / Config (5) |
|
Resources exposed via URI templates:
URI template | Returns |
| YAML commit analysis |
| JIRA issue as JFM |
| JIRA issue body as ADF |
| Confluence page as JFM |
| Confluence page body as ADF |
| Embedded reference specs (e.g. |
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 mcpThis 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-mcpSmoke-test with the MCP Inspector
npx @modelcontextprotocol/inspector omni-dev-mcpThe 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 |
| Model for | model registry default |
| Tracing filter directive for the server |
|
| Cap on a tool response before truncation ( | 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-devScope 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.mdWork 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 2Command Options
Option | Description | Example |
| Generate fresh messages from the diffs alone (the default; conflicts with |
|
| Refine the existing messages instead of starting fresh (conflicts with |
|
| Enable contextual intelligence |
|
| Describe the work being done to steer suggestions |
|
| Override the context detected from the branch name |
|
| Custom context directory |
|
| Claude API model to use (defaults from settings) |
|
| Beta header for API requests (model-gated) |
|
| Number of parallel commit processors (default: 4) |
|
| Skip cross-commit coherence refinement pass |
|
| Skip AI; amend to a deterministic type/scope suggestion, leaving conforming commits untouched |
|
| Apply without confirmation |
|
| Allow amending commits already in remote main branches |
|
| Validate the messages after applying |
|
| Save to file without applying |
|
| Only show errors/warnings |
|
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 changesAfter: 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 performanceWorkflow 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 reviewContributing
We welcome contributions! Please see our Contributing Guidelines for details.
Development Setup
Clone the repository:
git clone https://github.com/rust-works/omni-dev.git cd omni-devInstall Rust (if you haven't already):
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | shBuild the project:
cargo buildRun the build script (includes tests, linting, and formatting):
./scripts/build.shOr run individual steps:
cargo test # Run tests cargo clippy # Run linting cargo fmt # Format code
📚 Documentation
Getting Started - 10-minute walkthrough from install to first AI-improved commit (start here)
User Guide - Comprehensive usage guide with examples
Configuration Guide - Set up contextual intelligence
Why JFM? - Why omni-dev edits Atlassian content as Markdown instead of raw ADF
API Documentation - Rust API reference
Troubleshooting - Common issues and solutions
Examples - Real-world usage examples
Release Process - For contributors
🔧 Requirements
Rust: 1.88+ (for installation from source)
Claude API Key: Required for AI-powered features
See Authentication for setup (env var,
.env, or CI/CD secrets)
AI Model Selection: Optional configuration for specific models
View available models:
omni-dev config models showPick per-invocation with
--modelon an AI command, or configure viaOMNI_DEV_MODEL/ the per-backend env chain (CLAUDE_MODEL,CLAUDE_CODE_MODEL,ANTHROPIC_MODELfor Claude-family backends;OPENAI_MODEL;OLLAMA_MODEL) or~/.omni-dev/settings.jsonSupports 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— sandboxedclaude -psubprocess 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 toolsai_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_searchA
Search Confluence pages using CQL (Confluence Query Language), e.g. space = ENG AND title ~ "architecture". Returns YAML with matching page IDs, titles, and space keys — feed an ID into confluence_read for the body. Use confluence_children/confluence_space_pages instead when you want to enumerate a known page tree or space rather than query by text. Mirrors omni-dev atlassian confluence search --cql.
Inputs: cql (required), limit.
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_user_searchB
Search Confluence users by display name or email. limit of 0 returns every match; defaults to 25. Mirrors omni-dev atlassian confluence user search.
Inputs: query (required), limit.
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_logs_searchA
Search Datadog log events with a logs query (e.g. service:api status:error) over a time range (default last 15m). For the event/alert stream rather than logs, use datadog_events_list. 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). sort is timestamp-asc or timestamp-desc (default). Read-only. Mirrors omni-dev datadog logs search. Output is YAML.
Inputs: filter (required), to, from, sort, +1 more.
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_monitor_searchA
Free-text / faceted search across Datadog monitors (e.g. status:alert, type:metric tag:team:sre). Prefer this over datadog_monitor_list when filtering by status/facets rather than just name/tags; the response is a search envelope (monitors + paging metadata) rather than a plain array. limit of 0 (or omitted) auto-paginates up to 10000. Read-only. Mirrors omni-dev datadog monitor search. Output is YAML.
Inputs: query (required), limit.
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_link_createA
Create a typed link between two JIRA issues (e.g. Blocks, Relates). link_type is the type name (list options with jira_link_types); inward is the source issue and outward the target. To set hierarchy (Epic → Story / Story → Sub-task) use jira_link_parent instead. Returns YAML {status: ok}. Set dry_run: true to preview the request that would be sent (method, path, body) without creating the link. Mirrors omni-dev atlassian jira link create.
Inputs: inward (required), outward (required), link_type (required), dry_run.
jira_link_listA
List inward and outward links on a JIRA issue. Returns YAML with one entry per link (id, link_type, direction, linked_issue_key, linked_issue_summary). Mirrors omni-dev atlassian jira link list.
Inputs: key (required).
jira_link_parentA
Set a JIRA issue's parent — the system parent field for Epic → Story / Story → Sub-task hierarchy, distinct from the relationship links created by jira_link_create. parent is the parent issue key (e.g. the epic); child is the issue placed under it. Returns YAML {status: ok}. Set dry_run: true to preview the request that would be sent (method, path, body) without setting the parent. Mirrors omni-dev atlassian jira link parent.
Inputs: child (required), parent (required), dry_run.
jira_link_remote_createA
Add a remote (external URL) link to a JIRA issue — pointing out to a non-JIRA resource. url and title are required; summary, relationship, and global_id are optional (reusing an existing global_id updates that link instead of duplicating it). Returns YAML {status: ok, id}. Set dry_run: true to preview the request without creating it. Mirrors omni-dev atlassian jira link remote create.
Inputs: key (required), url (required), title (required), dry_run, +3 more.
jira_link_remote_deleteA
Delete a remote (external URL) link from a JIRA issue (by key + link_id from jira_link_remote_list). Irreversible: pass confirm: true to authorise — without it the tool refuses and makes no API call. Set dry_run: true to preview the request without deleting (and without requiring confirm). Returns YAML {status: ok}. Mirrors omni-dev atlassian jira link remote delete.
Inputs: key (required), confirm (required), link_id (required), dry_run.
jira_link_remote_listA
List remote (external URL) links on a JIRA issue — links pointing out to non-JIRA resources (Confluence pages, Bitbucket PRs, external trackers). Read-only. Returns YAML with one entry per remote link (id, optional global_id, optional relationship, object.{url, title, summary, icon}). Mirrors omni-dev atlassian jira link remote list.
Inputs: key (required).
jira_link_removeA
Remove a JIRA issue link by its link ID (use jira_link_list or jira_read to discover IDs). Destructive operation: callers must explicitly pass confirm: true for the removal to proceed; otherwise the tool refuses with an error. Returns YAML {status: ok}. Set dry_run: true to preview the request that would be sent (method, path) without removing the link — no confirm needed for a dry-run. Mirrors omni-dev atlassian jira link remove.
Inputs: confirm (required), link_id (required), dry_run.
jira_link_typesA
List the configured JIRA issue link-type catalogue (id, name, inward, outward). Global per JIRA instance — returns the configured types, not the ones used in any particular issue. Returns YAML. Mirrors omni-dev atlassian jira link types.
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_searchA
Search JIRA issues using a JQL query (e.g. project = PROJ AND status = Open ORDER BY created DESC; dates are YYYY-MM-DD). Returns matching issues as YAML. Provide either a raw jql string, or the convenience filters project / assignee / status (ANDed together) — at least one is required. limit defaults to 20; pass 0 for unlimited. To list issues on a board or sprint instead, use jira_board_issues / jira_sprint_issues.
Inputs: jql, limit, fields, status, +2 more.
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_user_searchA
Search JIRA users by display-name or email substring. Returns matches as YAML — each entry includes account_id, display_name, email_address (often redacted by GDPR), active, and account_type. Use the returned account_id as input to jira_write's assignee or reporter parameter. limit defaults to 25; pass 0 for unlimited. Atlassian matches substrings on display name and email — try a shorter or alternate spelling if the first attempt returns nothing.
Inputs: query (required), limit.
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.
log_searchA
Search the local omni-dev request log — every CLI/MCP invocation and the HTTP requests it issued — and return matching records as text. Read-only. Mirrors omni-dev log (the --follow tail has no MCP form). All filters are optional and AND-ed: since/until (30m/2h, a date, or an RFC3339 timestamp), method, status (200/5xx/4xx,5xx), service, command, url, grep (regex), fuzzy/query (mini-language), id. format is oneline (default), json (verbatim NDJSON), or full; limit keeps the most recent N.
Inputs: id, url, grep, fuzzy, +9 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
Scored across 138 tools
Domain prefixes (jira_, confluence_, datadog_, git_, snowflake_, transcript_youtube_) cleanly partition the surface, and within each domain the descriptions go out of their way to say when to use a sibling tool instead. A few genuine overlaps remain: jira_edit vs jira_write, jira_transition_list vs jira_transition with list=true, jira_attachment_images vs jira_attachment_download, and jira_comment (action-based list/add) sitting alongside separate edit/delete tools.
The dominant convention is domain_resource_action in snake_case (jira_version_create, confluence_comment_reanchor, datadog_metrics_query), which is applied consistently across the vast majority of the 138 tools. Deviations are minor: verb-first names (ai_chat, git_create_pr, git_staged_commit), verb-less names (confluence_children), action-param tools (jira_comment), and a few one-off prefixes (jev_route, log_search, config_models_show, atlassian_convert).
138 tools is an extreme mismatch for a single MCP server surface; even accepting that omni-dev mirrors a whole CLI across Jira, Confluence, Datadog, git, Snowflake, YouTube and more, this is far past the point where an agent can hold the toolset in context or select reliably. Several tools are near-duplicates that could be collapsed (jira_transition_list, jira_attachment_images, git_lint_commits vs git_check_commits).
Coverage is unusually deep: Jira has full lifecycle CRUD for issues, comments, attachments, worklogs, sprints, versions, components, links, watchers and transitions plus discovery helpers (field list/options, create-meta, link types); Confluence has pages, comments, labels, attachments, restrictions, history, compare and download. Remaining gaps are real but workaroundable: Datadog is entirely read-only (no mute/create downtime/update monitor), and there is no Jira issue-type or Confluence blog-post surface.
Maintenance
Related MCP Connectors
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Monitor MCP servers, API contracts and AI outputs for schema drift. Alerts on breaking changes.
Hosted MCP server: convert PDFs to clean, LLM-ready Markdown with tables, formulas and OCR.
Document conversion MCP server: PDF to Markdown, image OCR, spreadsheet parsing.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceModel Context Protocol (MCP) server for Atlassian Cloud products (Confluence and Jira). This integration is designed specifically for Atlassian Cloud instances and does not support Atlassian Server or Data Center deployments.6,121MIT
- AlicenseNot gradedqualityDmaintenanceProduction-ready MCP server for Atlassian Jira and Confluence, providing tools for issue management, page retrieval, and content operations.115 npm1MIT
- AlicenseNot gradedqualityDmaintenanceModel Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Supports both Cloud and Server/Data Center deployments.MIT
- AlicenseAqualityCmaintenanceAn MCP server for reading and writing Confluence pages in native Atlassian Document Format (ADF), enabling precise edits at the document node level without loss of formatting.43MIT