Loading ToolBench
AI-powered git commit rewriter, PR generator, and MCP server for Jira, Confluence, Datadog, Gmail, and Drive.
The server provides 8 tools with generally clear descriptions and mostly complete parameter schemas. Tool names follow verb_noun patterns well (ai_chat, claude_skills_sync, atlassian_convert). Descriptions are substantial (140-450 chars average) and explain purpose and use cases. However, there are significant gaps: (1) No input schemas are visible in the provided source code, parameter types, descriptions are inferred from the description text rather than machine-readable JSON Schema, (2) Output schemas are completely undocumented, callers must infer return structure from descriptions, (3) Tool annotations (readOnlyHint, destructiveHint) are absent despite clear mutations (write-type tools), (4) Error handling descriptions are vague (e.g. 'returns a tool error containing the same diagnostic' in ai_chat but no structured error schema), (5) No pagination or result-limiting patterns for list-like operations. The browser_bridge_request and claude_skills_* tools demonstrate good domain-specific design (mutually exclusive params, clear risk callouts), but lack machine-readable formalization.
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.
Report which Atlassian credential scopes have credentials configured. Returns boolean presence flags only — NEVER includes the email, API token, or any other secret. The instance URL (non-secret) is returned verbatim. Checks local configuration only; it does NOT call the Atlassian API 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.
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`.
No JSON Schema definitions visible for tool inputs. Parameter types, constraints, and enums are documented only in human-readable descriptions, not in machine-parseable schemas. This violates the pattern:constrained-input and pattern:tool-description patterns, LLMs and clients cannot validate input programmatically.
No output/return schemas documented. Callers cannot determine what fields to expect from each tool's response, making it difficult for LLMs to plan downstream operations or extract specific data. Tools return YAML/JSON but structure is undocumented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
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.
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`.
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`.
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`.
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).
Write-type tools lack destructiveHint/idempotentHint annotations. claude_skills_sync, claude_skills_clean, and browser_bridge_request (with non-GET methods) mutate state but are not formally marked as destructive. This leaves agents uncertain about retry safety and idempotency.
Error handling is under-specified. ai_chat mentions 'returns a tool error containing the same diagnostic' but no schema for the error response exists. browser_bridge_request references 'Streaming responses are not supported here' but does not document what error is returned if streaming is attempted. No recovery guidance per pattern:recovery-guide.
Mutually exclusive parameters documented only in prose. ai_chat requires exactly one of message or message_path, but this constraint is embedded in the description, not in formal schema constraints. browser_bridge_request similarly has implicit dependencies (e.g., control_port, token_file, allow_origin) that are not formally declared.
No input validation or constraint documentation in formal schema. Example: atlassian_convert's 'direction' enum is named but not formally constrained; config_models_show has empty input {} with no indication this is intentional.