What can you do with this server?

OzBridge exposes Warp Oz AI agent capabilities as an MCP server, allowing any MCP-compatible client (Claude Code, Cursor, Codex CLI, VS Code Copilot) to run, manage, and configure Warp Oz agents locally or in the cloud. * oz_agent_run: Execute a Warp Oz AI agent locally in your workspace with a natural-language prompt. Supports selecting a model, agent skill (from a 7-stage pipeline), and agent profile. Runs synchronously and returns full output without consuming cloud credits. * oz_agent_run_cloud: Launch a Warp Oz AI agent on Warp's cloud infrastructure. ⚠️ Consumes Warp credits. Returns a run ID immediately (non-blocking); poll for results using oz_run_get. Supports model, skill, and cloud environment selection. * oz_run_get: Fetch the status and full output of any Oz run by its ID. Read-only and safe to call repeatedly for polling a cloud run until it reaches a terminal state (SUCCEEDED/FAILED). * oz_run_list: List recent Oz agent runs (newest first), with optional filtering by status (all, active, completed, or specific statuses like QUEUED, INPROGRESS, FAILED) and an optional result limit. * oz_list_models: Discover all AI model IDs available to your Warp account and see the current default model. Useful before specifying a model in run commands. * oz_set_default_model: Persistently set the default Oz model for all OzBridge surfaces by writing to the workspace .warp/warp-bridge.yaml config file. Accepts any valid model ID or auto to let Warp choose.

Which integrations are available for this server?

Allows interacting with Warp Oz for running AI agents locally or in the cloud, managing runs, schedules, and models from any MCP client.

OzBridge

by sena-labs

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

OzBridge — Warp Oz for any IDE or agent, via MCP

Build VS Code License: MIT OzBridge screenshot

What is OzBridge?

OzBridge is an open-source Model Context Protocol (MCP) server and VS Code extension that runs Warp Oz cloud and local agents from any MCP-compatible client — GitHub Copilot Chat, Claude Code, Cursor and Codex CLI.

Independent extension — not affiliated with, endorsed by, or sponsored by Warp, Inc. Warp™ and Oz™ are trademarks of Warp, Inc., used here nominatively only to describe interoperability. OzBridge uses solely Warp's documented public interfaces (the oz CLI, the Model Context Protocol, and the WARP_OUTPUT_FORMAT env var); it does not modify, reverse-engineer, or compete with Warp. See DISCLAIMER.

Run it embedded in VS Code — where Oz shows up natively as the @oz Chat Participant and as Agent-Native Language Model Tools that Copilot Agent mode invokes autonomously — or expose the same Oz toolset over HTTP+SSE so Claude Code, Cursor and Codex drive Oz too. No editor at all? Ship the standalone @sena-labs/oz-mcp-server and point any MCP client at it.

flowchart LR
    subgraph clients["MCP clients"]
        CC["Claude Code"]
        CU["Cursor"]
        CX["Codex CLI"]
    end
    VSC["VS Code<br/>Copilot Chat"]

    clients -->|"HTTP + SSE"| BR
    VSC -->|"@oz participant<br/>LM Tools"| BR

    BR["OzBridge<br/>(6 MCP tools)"] -->|"spawn"| CLI["oz CLI"]
    CLI -->|"local run"| WS["Your workspace"]
    CLI -->|"cloud run"| CLOUD["Warp Oz cloud"]

Related MCP server: memorix

Feature gallery

Runs & Resources

OzBridge sidebar with active runs, history and schedules

Warp Drive

Warp Drive prompt and skills preview inside VS Code

MCP bridge

Embedded MCP bridge status with registered clients

Dashboard

OzBridge dashboard with analytics and failure triage

New to Warp or to VS Code extensions? The Quick Start guide is a step-by-step visual walkthrough — prerequisites, per-OS install, first run, every slash command, settings and troubleshooting — written for readers with no prior setup. Full documentation site: https://sena-labs.github.io/OzBridge/.

Features

MCP bridge — Warp Oz for any client — expose the Oz toolset as a Model Context Protocol server over HTTP+SSE so Claude Code, Cursor and Codex drive Oz through the same tools Copilot sees. Run it embedded in VS Code (opt-in) or fully standalone via @sena-labs/oz-mcp-server. See docs/MCP.md.
@oz Chat Participant — interact with Warp Oz agents from the VS Code chat panel.
Agent-Native Language Model Tools — Copilot Agent mode can invoke Warp Oz directly, without typing @oz.
One-click model selection — pick the Oz model from a QuickPick (OzBridge: Select Model), the $(sparkle) status-bar indicator, or @oz /models <id> — no hand-typing an id into settings. Agents switch it via the MCP tools oz_list_models / oz_set_default_model.
Warp sidebar + status bar — Activity Bar view with Active Runs, History, Schedules, Environments, MCP Servers and Secrets, plus a $(cloud) Warp: N active indicator and a $(sparkle) <model> model indicator (click to switch).
Context variables & Warp handoff — inline #warp.env, #warp.profile, #warp.model, #oz.history and #oz.run/<id> tokens expanded into any /run or /cloud prompt, plus a one-click handoff to an actual Warp terminal.
Per-workspace config — optional .warp/warp-bridge.yaml committed to the repo overrides ozBridge.* settings for everyone who opens the project. Precedence: YAML > VS Code settings > defaults. Secrets like mcpBearerToken and platform-specific ozPath are deliberately excluded.
9 slash commands covering the full agent workflow: /run, /cloud, /status, /history, /schedule, /models, /mcp, /config, /init.
IDE context injection — automatically includes workspace path, active file, selection and diagnostics in every prompt.
Agent skill detection — maps prompt keywords to the 7-agent pipeline (spec, design, implement, review, test, deploy, maintenance).
Cloud run polling — exponential-backoff polling with real-time progress updates in the chat stream.
Robust JSON parser — 5-level fallback for mixed text/JSON CLI output.
Configurable — every setting is exposed via the VS Code Settings UI under ozBridge.*.
Minimal runtime footprint — one bundled workspace package (copilot-chat-toolkit) plus the vscode API; no third-party network code. Production bundle ~160 KB.

Requirements

VS Code ≥ 1.96.0 (the @oz participant requires the stable Chat Participant API; LM Tools additionally require vscode.lm.registerTool).
Warp Terminal installed, with the oz CLI accessible in PATH.
A Warp account, signed in via oz login.
GitHub Copilot Chat extension (optional but required to actually invoke @oz or use Agent mode tools).

Installation

From a registry

Starting with v0.9.0, OzBridge is published to both registries on every tagged release.

VS Code Marketplace (Stable / Insiders / Cursor with Microsoft marketplace access):

code --install-extension sena-labs.ozbridge

Open VSX (VSCodium, Gitpod, Theia, Cursor with Open VSX mirror):

codium --install-extension sena-labs.ozbridge
# or, inside the editor GUI, search for "OzBridge" on open-vsx.org

Direct links:

Marketplace — https://marketplace.visualstudio.com/items?itemName=sena-labs.ozbridge
Open VSX — https://open-vsx.org/extension/sena-labs/ozbridge

From VSIX (local)

Option A — VS Code GUI (recommended):

Press Ctrl+Shift+P (or Cmd+Shift+P on macOS).
Type "Extensions: Install from VSIX…".
Select the ozbridge.vsix file.

Option B — CLI:

code --install-extension ozbridge.vsix

Note: on Windows code may not be in your PATH. Use the full path or the GUI method above.

From source

git clone https://github.com/sena-labs/OzBridge.git
cd OzBridge
npm install
npm run build

Then press F5 in VS Code to launch the Extension Development Host with the built extension loaded.

Verify the installation

Open the Copilot Chat panel (Ctrl+Shift+I / Cmd+Shift+I).
Type @oz /config and submit.
The panel should show a table with the current configuration and the detected Oz CLI path. If the CLI is missing you will see an "Install Warp" action button that opens the download page.

Connect your MCP client

OzBridge exposes the same six Oz tools to every MCP client. Start the bridge first — either enable the embedded server in VS Code ("ozBridge.mcpEnabled": true, then OzBridge MCP: Start) or run the standalone package:

npx -y @sena-labs/oz-mcp-server

Both listen on http://127.0.0.1:3847/sse by default. Set ozBridge.mcpBearerToken to require an Authorization: Bearer <token> header; omit the headers block below when auth is disabled.

How do I use Warp Oz in Claude Code?

Add to ~/.claude.json:

{
  "mcpServers": {
    "oz-bridge": {
      "type": "sse",
      "url": "http://127.0.0.1:3847/sse",
      "headers": { "Authorization": "Bearer my-secret" }
    }
  }
}

How do I use Warp Oz in Cursor?

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "oz-bridge": {
      "url": "http://127.0.0.1:3847/sse",
      "headers": { "Authorization": "Bearer my-secret" }
    }
  }
}

How do I use Warp Oz in Codex CLI?

Add to ~/.codex/config.toml:

[[mcp.servers]]
name = "oz-bridge"
url = "http://127.0.0.1:3847/sse"
authorization = "Bearer my-secret"

How do I use Warp Oz in VS Code?

No MCP wiring needed — install the extension and Oz is available immediately as the @oz chat participant and as Language Model Tools that Copilot Agent mode calls on its own. See Usage.

Protocol details, endpoint reference and a raw-curl cheatsheet live in docs/MCP.md.

Usage

Chat Participant (`@oz`)

Open the Copilot Chat panel and type @oz followed by your request:

@oz fix the failing test in src/auth/login.ts

The extension injects an IDE context block (workspace path, active file, selection, diagnostics) before the prompt and runs the Oz agent. Results stream back as markdown with action buttons (e.g. Retry, Open run).

Slash Commands

Command	Description	Example
`/run`	Run an Oz agent locally in the workspace	`@oz /run refactor this function`
`/cloud`	Run an Oz agent in the cloud (credits)	`@oz /cloud deploy to staging`
`/status`	Show active runs (`QUEUED` / `INPROGRESS`) or detail by ID	`@oz /status` or `@oz /status <runId>`
`/history`	Show completed runs (`SUCCEEDED` / `FAILED`) with optional filter	`@oz /history`, `@oz /history succeeded`, `@oz /history <runId>`
`/schedule`	Create and manage scheduled runs	`@oz /schedule create daily "0 9 * * *" "Run linting"`
`/models`	List available AI models, or set the default with `/models <id>`	`@oz /models` · `@oz /models claude-4-8-opus-max`
`/mcp`	List configured MCP servers	`@oz /mcp`
`/config`	Show current configuration	`@oz /config`
`/init`	Scaffold Warp Skills and Rules files	`@oz /init`

`/history` filters

/history               — list all completed runs (SUCCEEDED + FAILED)
/history succeeded     — only SUCCEEDED runs
/history failed        — only FAILED runs
/history <runId>       — show details for a specific run

`/schedule` sub-commands

/schedule list                                    — List all schedules
/schedule create <name> "<cron>" "<prompt>"       — Create a schedule
/schedule pause <id>                              — Pause a schedule
/schedule unpause <id>                            — Resume a schedule
/schedule delete <id>                             — Delete a schedule

Agent Mode — Language Model Tools

In GitHub Copilot Chat Agent mode, Copilot can call Warp Oz directly through registered Language Model Tools — you don't need to prefix your request with @oz. Copilot selects the right tool based on the prompt and its declared modelDescription.

Tool	Reference	Behaviour
`oz_run_local`	`#ozRunLocal`	Runs a local Oz agent in the current workspace. Injects IDE context by default (`includeIdeContext: false` to opt out).
`oz_run_cloud`	`#ozRunCloud`	Launches a cloud Oz agent. Shows a confirmation dialog before consuming Warp credits. Polls to terminal state by default (`wait: false` returns immediately with the run id).
`oz_get_run`	`#ozGetRun`	Fetches status + output of a specific run by id. Read-only.
`oz_list_runs`	`#ozListRuns`	Lists recent runs with a status filter (`all`, `active`, `completed`, or a raw `OzRunStatus`) and optional `limit`. Read-only.

Examples:

# Agent mode picks oz_run_local automatically:
Run the unit tests locally via Oz.

# Explicit tool reference (prefix with #):
Run this refactor on cloud: #ozRunCloud refactor src/auth to hexagonal architecture

# Query a previous run:
Check run #ozGetRun for run id run-abc123.

Each tool is declared in package.json under contributes.languageModelTools with a strict JSON inputSchema, so the model receives accurate type hints at tool-call time. Cloud tools always show a confirmation dialog before running, regardless of the user's Bypass Approvals preference.

Sidebar & Status Bar

The extension contributes a dedicated Activity Bar view (OzBridge → Runs & Resources) with five collapsible categories:

Active Runs — QUEUED + INPROGRESS (live-refreshed every 10 s).
History — SUCCEEDED + FAILED, capped at 20 entries per refresh.
Schedules — cron jobs from oz schedule list.
Environments — cloud environments from oz environment list.
MCP Servers — MCP integrations from oz mcp list.

Right-click menu actions:

Copy ID on any run / schedule / environment / MCP node.
Open in Browser on a run node (opens app.warp.dev/agents/<id>).
Pause / Resume / Delete on schedule nodes (delete asks for confirmation).

A status bar item ($(cloud) Warp: N active, right-aligned) mirrors the Active Runs count in real time and switches to warningBackground at 1–2 active runs or errorBackground at 3+. Clicking the indicator focuses the OzBridge sidebar.

Prompt variables

Inside any @oz /run … or @oz /cloud … prompt you can embed a small set of tokens that the extension resolves locally before sending the prompt to the Oz CLI. Unknown tokens (e.g. #some.other) are passed through unchanged.

Token	Expands to
`#warp.env`	Value of `ozBridge.defaultEnvironment` (or `(no default environment)` when empty).
`#warp.profile`	Value of `ozBridge.defaultProfile`.
`#warp.model`	Value of `ozBridge.defaultModel`.
`#oz.history`	Markdown table of the last 10 runs from `oz run list`.
`#oz.run/<id>`	Fenced JSON payload from `oz run get <id>` (truncated at 2 000 chars).

Example:

@oz /cloud deploy branch #warp.env profile=#warp.profile given the last runs:\n#oz.history

Hand off to Warp

Two commands open a real Warp terminal (Warp ≥ 0.2024.x) via the warp://action/new_tab URI scheme:

Warp: Hand off to Warp terminal… (Command Palette) — asks for a prompt and runs oz agent run --prompt "<prompt>" in a new Warp tab.
Warp: Hand off run to Warp terminal (sidebar context menu on any run node) — runs oz run get <runId> so you can drill into the run directly in the terminal.

If the warp:// URL handler is not registered on the current platform, the extension shows a modal with the exact command to copy into any shell as a fallback.

Tools

Six MCP tools are exposed over the bridge. Copilot Agent mode invokes them natively in VS Code; Claude Code, Cursor and Codex reach the same set through the MCP server, embedded or standalone.

Tool	Purpose
`oz_agent_run`	Run `oz agent run` locally with a prompt. Returns the full run payload.
`oz_agent_run_cloud`	Launch a cloud run. Consumes Warp credits.
`oz_run_get`	Fetch a run's status and output by id. Read-only.
`oz_run_list`	List recent runs; filter by `all` / `active` / `completed` / raw status, plus a numeric `limit`.
`oz_list_models`	List the AI model ids available to the account and report the current default. Read-only.
`oz_set_default_model`	Set the default Oz model by writing `defaultModel` into the workspace `.warp/warp-bridge.yaml`.

The full JSON inputSchema for each tool is emitted verbatim by tools/list. See docs/MCP.md for protocol details, a raw-curl cheatsheet and the endpoint reference.

Configuration

All settings live under ozBridge.* in VS Code Settings (File → Preferences → Settings) or can be edited in settings.json.

Per-workspace overrides (`.warp/warp-bridge.yaml`)

Commit a .warp/warp-bridge.yaml at the root of your repository and OzBridge will merge its values on top of the VS Code settings for everyone who opens the project. The file is reloaded automatically when it is created, changed or deleted — no VS Code reload required.

# .warp/warp-bridge.yaml — committed to Git, shared across the team.
defaultProfile: team-shared
defaultEnvironment: staging
timeoutMs: 600000
mcpEnabled: true
mcpPort: 3900
mcpBindAddress: "127.0.0.1"

Supported keys: defaultModel, defaultProfile, defaultEnvironment, timeoutMs, maxOutputChars, cloudPollingIntervalMs, cloudPollingTimeoutMs, mcpEnabled, mcpPort, mcpBindAddress.

Deliberately excluded:

ozPath — platform-specific, must live in user settings.
mcpBearerToken — secret, should never be committed.

Unknown keys and keys with the wrong type are logged to the OzBridge output channel and ignored, so a typo never breaks the extension.

Setting	Default	Description
`ozBridge.ozPath`	`oz`	Path to the Oz CLI executable
`ozBridge.defaultModel`	`auto`	Default AI model for agent runs
`ozBridge.defaultProfile`	`Default`	Default Oz agent profile
`ozBridge.defaultEnvironment`	(empty)	Default cloud environment name
`ozBridge.timeoutMs`	`300000`	Timeout for local agent runs (5 min)
`ozBridge.cloudPollingIntervalMs`	`5000`	Initial cloud polling interval
`ozBridge.cloudPollingTimeoutMs`	`1800000`	Max cloud polling duration (30 min)
`ozBridge.maxOutputChars`	`15000`	Max characters shown before truncation

Architecture

The extension follows a layered architecture with dependency injection at the composition root (src/extension.ts). Each layer has a single responsibility:

Layer	Files	Responsibility
Types	`types/index.ts`	Interfaces, error classes, config shape, constants
Parsers	`parsers/jsonParser.ts`, `parsers/outputFormatter.ts`	JSON parsing (5-level), chat stream rendering
Services	`services/ozCliService.ts`, `configManager.ts`, `contextCollector.ts`, `runPoller.ts`, `logger.ts`	CLI execution, settings, IDE context, polling, logging
Commands	`commands/router.ts` + 9 command files	Slash-command dispatch and business logic
Tools	`tools/*`	VS Code Language Model Tool implementations
Participant	`participant/handler.ts`, `followups.ts`	Chat Participant registration and follow-ups

Folder structure

src/
├── types/index.ts          — Contracts: interfaces, errors, config
├── parsers/
│   ├── jsonParser.ts       — Robust 5-level JSON parser
│   └── outputFormatter.ts  — Chat stream formatting & truncation
├── services/
│   ├── configManager.ts    — VS Code settings wrapper with caching
│   ├── contextCollector.ts — IDE context gathering
│   ├── ozCliService.ts     — Core CLI execution via child_process
│   ├── runPoller.ts        — Async polling with exponential backoff
│   └── logger.ts           — Centralised extension logging
├── commands/
│   ├── router.ts           — Slash-command dispatch
│   └── {9 command files}   — One handler per /command
├── tools/
│   ├── baseTool.ts         — Shared helpers (textResult, errorResult)
│   ├── runLocalTool.ts     — oz_run_local
│   ├── runCloudTool.ts     — oz_run_cloud (with confirmation)
│   ├── getRunTool.ts       — oz_get_run
│   ├── listRunsTool.ts     — oz_list_runs
│   └── index.ts            — registerWarpTools()
├── participant/
│   ├── handler.ts          — Chat Participant registration
│   └── followups.ts        — Contextual follow-up suggestions
└── extension.ts            — Entry point: compose & register

Data flow

User types @oz /run implement auth in Copilot Chat.
VS Code dispatches the request to the @oz Chat Participant.
CommandRouter maps /run to the createRunCommand handler.
Handler calls ContextCollector.gather() for IDE context.
Handler calls OzCliService.agentRun(), which spawns oz as a child process.
JSON output is parsed via the 5-level jsonParser.
OutputFormatter renders the result as markdown in the chat stream.

Development

# Install dependencies
npm install

# Type-check
npm run compile

# Build (esbuild)
npm run build

# Run tests
npm test

# Tests with coverage report
npm run test:coverage

# Watch mode (dev)
npm run watch

# Clean build artifacts
npm run clean

# Package VSIX for distribution
npm run package

Test Suite

1,400+ tests across 100+ files
High test-to-code ratio
Framework: Vitest v4.0.18

Contributing

Contributions are welcome. Please read CONTRIBUTING.md before submitting changes.

Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

Make sure all tests pass before submitting:

npm run compile && npm test

See also the Code of Conduct and the Security Policy.

Troubleshooting

`oz` command not found

Ensure Warp is installed and the oz CLI is available in your PATH.

OS	Typical path
macOS	`/Applications/Warp.app/Contents/MacOS/oz`
Linux	`~/.warp/bin/oz`
Windows	`C:\Users\<user>\AppData\Local\Programs\Warp\bin\oz.cmd`

# Verify oz is available
which oz   # macOS / Linux
where oz   # Windows (PowerShell)

If oz is in PATH but the extension still reports it as unavailable, type @oz /config in the Copilot Chat panel — this triggers extension activation and the first CLI check. You can also set an explicit path in Settings → Extensions → OzBridge → Oz Path.

Authentication errors

Run oz login in a terminal to re-authenticate, or use the Login Warp button that appears in the error message inside the chat panel.

Timeout errors

Increase the timeout in Settings → Extensions → OzBridge → Timeout (ms). The default is 300 000 ms (5 minutes). For large-scale agent runs consider raising it to 600 000 ms. Cloud runs have a separate, longer timeout controlled by cloudPollingTimeoutMs.

Extension not activating

The extension activates only when the @oz participant is invoked in Copilot Chat (or when Copilot Agent mode calls one of the LM Tools). To activate it manually:

Open the Chat panel (Ctrl+Shift+I).
Type @oz followed by any command (e.g. @oz /config).

Make sure you have VS Code ≥ 1.96.0 and the GitHub Copilot Chat extension installed and signed in.

FAQ

Q: Does OzBridge work with Cursor, Claude Code and Codex? A: Yes. All three are MCP clients — point them at the bridge endpoint and they get the same six Oz tools Copilot sees. Copy-paste configs are in Connect your MCP client.

Q: Do I need VS Code at all? A: No. The standalone @sena-labs/oz-mcp-server runs via npx with no editor involved; VS Code is only required for the @oz chat participant and the sidebar.

Q: What is the difference between a local run and a cloud run? A: A local run spawns the oz CLI in your workspace — no Warp credits, full access to your files. A cloud run executes on Warp's infrastructure, consumes credits, and runs detached from your machine. Both are reachable from every client.

Q: Does this extension require a Warp subscription? A: A free Warp account is sufficient for local agent runs. Cloud runs may require a paid plan depending on usage. Check your account at app.warp.dev.

Q: Can I use a custom model? A: Yes — set ozBridge.defaultModel in VS Code settings or pass it inline with /run --model gpt-4o. To see all available models, use /models.

Q: Which operating systems are supported? A: macOS, Linux and Windows are all natively supported. The extension works on any platform where VS Code and the Oz CLI can run. On Windows the extension automatically handles .cmd wrappers.

Q: How do I report a bug? A: Open an issue using the bug report template. Include your OS, VS Code version, extension version and steps to reproduce.

Q: Can I use this extension with GitHub Copilot Chat? A: Yes — this extension is a VS Code Chat Participant. It appears as @oz in the Copilot Chat panel. You need GitHub Copilot Chat installed and active.

Q: How do I update the Oz CLI? A: The Oz CLI ships with Warp. Updating Warp to the latest version automatically updates the Oz CLI.

macOS: brew upgrade warp
Windows/Linux: download the latest installer from warp.dev.

Q: What happens if the agent run times out? A: The extension shows a timeout error with the configured limit in seconds. You can increase the timeout via ozBridge.timeoutMs in settings. Cloud runs have a separate, longer timeout controlled by cloudPollingTimeoutMs.

Q: Can I run multiple agents in parallel? A: Yes — each /run or /cloud command spawns an independent process. Multiple chat messages can trigger concurrent agent executions.

License

This project is licensed under the MIT License. See the LICENSE file for details.

Disclaimer

OzBridge is an independent project developed by Ivan Sena under the Sena Labs name. It is not affiliated with, endorsed by, sponsored by, or officially associated with Warp, Inc., Microsoft, GitHub, or Visual Studio Code.

Warp™ and Oz™ are trademarks of Warp, Inc.; other names may be trademarks of their respective owners. They are used here nominatively only to describe interoperability. OzBridge uses solely Warp's documented public interfaces (the oz CLI, the Model Context Protocol, and WARP_OUTPUT_FORMAT); it does not modify, reverse-engineer, or compete with Warp.

This extension is provided "as is", without warranty of any kind. Use it at your own risk. See DISCLAIMER.md for details.

Available Tools

6 tools

oz_agent_runA

Run a Warp Oz AI agent locally in the host workspace and return its full output synchronously. Runs oz agent run with your prompt and blocks until the agent finishes. Use for local coding tasks — refactor, write/run tests, debug, explain code — that should NOT consume cloud credits; for cloud execution call oz_agent_run_cloud instead. NOT read-only: the agent may create or modify files in the workspace. Requires the oz CLI on PATH (install Warp).

ParametersJSON Schema

Name	Required	Description
`model`	No	AI model id to use, from `oz_list_models` (e.g. `claude-4-8-opus-max`). Omit to use the configured default (`auto` lets Warp choose).
`skill`	No	Agent skill id from the 7-stage pipeline (e.g. `5-test-agent`). Omit to let the CLI choose one based on the prompt.
`prompt`	Yes	Natural-language instruction for the agent, e.g. "add unit tests for src/auth.ts".
`profile`	No	Oz agent profile name (managed in the Warp app under Settings → AI → Profiles). Omit to use the default profile.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It clearly states the tool is synchronous, local, and not read-only (may create or modify files). It does not mention rate limits or detailed auth, but the key behavioral traits are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences, front-loaded with the core purpose, followed by usage, behavioral note, and prerequisite. It is concise and each sentence adds value, though it could be slightly more compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity and lack of output schema, the description covers the main aspects: local execution, synchronous blocking, file modification, and prerequisites. It is fairly complete for an agent-run tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds slight value by clarifying default behavior for model and skill, but does not significantly enhance understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs a Warp Oz AI agent locally, using 'oz agent run', and distinguishes it from cloud execution by naming the sibling `oz_agent_run_cloud`. The verb 'run' and resource 'agent' are explicit, and the purpose is well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use the tool (local coding tasks, not consuming cloud credits) and when not to (cloud execution, pointing to `oz_agent_run_cloud`). It also lists example tasks and mentions the prerequisite of having the `oz` CLI on PATH.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

oz_agent_run_cloudA

Launch a Warp Oz AI agent in Warp's cloud (not on the local machine). ⚠️ CONSUMES WARP CREDITS — confirm with the user before calling. Returns the run id immediately WITHOUT waiting for completion; poll the terminal status and output with oz_run_get, or find the run later via oz_run_list. Requires the oz CLI on PATH and a Warp account with cloud credits.

ParametersJSON Schema

Name	Required	Description
`model`	No	AI model id to use, from `oz_list_models`. Omit to use the configured default.
`skill`	No	Agent skill id (e.g. `5-test-agent`). Omit to auto-select from the prompt.
`prompt`	Yes	Natural-language instruction for the cloud agent.
`environment`	No	Cloud environment id or name to run in. Omit to use the configured default, or the first available environment.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses key behavioral traits: credits consumed, returns immediately without waiting, requires CLI and account. No annotations to contradict. Could add details on error handling or limits, but covers main points well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise with three front-loaded sentences covering purpose, warnings, and post-call behavior. No extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers invocation, post-call polling, and prerequisites. Without output schema, could specify return type more explicitly, but 'returns the run id' is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% description coverage, so baseline is 3. Description does not add significant meaning beyond what's already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Launch a Warp Oz AI agent in Warp's cloud (not on the local machine)', specifying verb, resource, and location distinction from sibling tool oz_agent_run.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit warning about credit consumption with user confirmation, instructions for post-call polling via oz_run_get, and prerequisites (oz CLI, Warp account with credits). Clearly differentiates from local run.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

oz_list_modelsA

List the AI model ids available to the connected Warp Oz account (from oz model list) and report the current default. Read-only; takes no arguments. Call this first to discover valid ids before passing model to oz_agent_run / oz_agent_run_cloud, or before oz_set_default_model.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description transparently declares it is read-only and takes no arguments, which is sufficient for this simple tool. Minor omission: no mention of error cases or rate limits, but not critical.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loading the purpose and key constraints. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately indicates the output (list of IDs and current default). The tool is simple and the description covers its complete behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters are defined, so the description correctly notes 'takes no arguments'. This adds clarity beyond the empty schema, earning a baseline score of 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists AI model IDs and reports the current default, distinguishing it from sibling tools like oz_agent_run and oz_set_default_model by emphasizing its discovery role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call this first to discover valid IDs before using other tools, providing clear when-to-use guidance and naming specific alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

oz_run_getA

Fetch the current status and output of a single Warp Oz run by its id. Read-only and idempotent — safe to call repeatedly while polling a cloud run to completion (SUCCEEDED / FAILED). Typically called after oz_agent_run_cloud, which returns the run id; ids also come from oz_run_list.

ParametersJSON Schema

Name	Required	Description	Default
`runId`	Yes	Run identifier as returned by `oz_agent_run_cloud` or `oz_run_list`.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description carries full burden. States read-only and idempotent, safe for polling. Does not detail output structure, but parameter coverage is high.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with core purpose, then additional usage context. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with sibling context, description covers purpose, usage, return information (status and output), and source of parameter. Complete and self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 100% (baseline 3). Description adds value by explaining where runId originates (oz_agent_run_cloud or oz_run_list), beyond schema's static description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states fetching status and output of a single run by id, with specific verb and resource. Distinguishes from siblings like oz_run_list (list vs single) and mentions typical predecessor tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states it is typically called after oz_agent_run_cloud and ids come from oz_run_list. Does not explicitly say when not to use, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

oz_run_listA

List recent Warp Oz runs (id, status, timing), newest first. Read-only. Use to discover run ids to pass to oz_run_get, or to review recent agent activity.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of runs to return after filtering (positive integer). Omit for no cap.
`status`	No	Filter by run status. `all` (default) = no filter; `active` = QUEUED\|INPROGRESS; `completed` = SUCCEEDED\|FAILED; or pass one exact status value.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Declares 'Read-only' and describes return fields (id, status, timing) and ordering. Since no annotations exist, the description adequately covers behavioral traits for a non-destructive list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. Front-loaded with purpose and key info, then usage guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Explains output (id, status, timing) and ordering, plus usage context linking to sibling tool. Lacks mention of default cap or pagination, but is sufficient for a simple list tool with two optional parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline applies. The description adds no additional meaning beyond what the schema provides for 'limit' and 'status', but the schema itself is clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('list'), resource ('Warp Oz runs'), and output fields ('id, status, timing') with ordering ('newest first'). It distinguishes from siblings by noting it is for discovering run ids to pass to `oz_run_get` or reviewing activity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states usage: 'Use to discover run ids... or to review recent agent activity.' Provides context for when to use, though does not explicitly mention when not to use or list alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

oz_set_default_modelA

Set the default Oz model for every OzBridge surface by writing defaultModel into the workspace .warp/warp-bridge.yaml (the highest-precedence config source). Persistent side effect: edits that file on disk. The id is validated against oz model list when reachable. Requires a workspace root (an extension workspace, or --cwd for the standalone server).

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes	Model id to set as default — one of the ids from `oz_list_models` (e.g. `claude-4-8-opus-max`, `gpt-5-5-high`), or `auto` to let Warp choose.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It discloses persistent side effects (edits file on disk), validation against oz model list, and configuration precedence. This is good transparency, though it could mention that the change is immediate and affects all surfaces.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no wasted words. It front-loads the main action, then covers side effects, validation, and requirements. Each sentence adds essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with no output schema and no annotations, the description covers purpose, side effects, validation, and prerequisites. It is fairly complete, though could mention return value or success indicator. Still strong given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema already describes the parameter well (model id from oz_list_models or 'auto'). The description adds context about validation but not new parameter semantics beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sets the default Oz model by writing to a specific config file, and distinguishes from sibling tools like oz_list_models (listing models) and oz_run tools (running queries). The verb 'set' and resource 'default Oz model' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions a requirement (workspace root) and validation behavior, but does not explicitly state when to use this tool versus alternatives or when not to use it. It implicitly suggests use when wanting to set a default model, but lacks direct comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesJun 26, 2026
- First observedoz_agent_run
- First observedoz_agent_run_cloud
- First observedoz_list_models
- First observedoz_run_get
- First observedoz_run_list
- First observedoz_set_default_model

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a distinct purpose: local vs cloud execution, listing models, fetching run status, listing runs, setting default model. No ambiguity between tools.

Naming Consistency5/5

All tools use consistent snake_case naming with 'oz_' prefix and clear verb_noun pattern (e.g., oz_agent_run, oz_list_models, oz_run_get).

Tool Count5/5

6 tools cover the core workflow of running AI agents (local/cloud, model discovery, status polling, configuration) without being too many or too few.

Completeness4/5

Covers all essential operations: run locally, run in cloud, list models, check status, list runs, set default. Lacks a cancel/abort for cloud runs, which is a minor gap.

Maintenance

ActivityActive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
Apuchat A
io.github.opcastil11
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
Communication Agent Orchestration
181
RogerRat A
io.github.opcastil11
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Communication Agent Orchestration
21
ContexterOAuth
io.github.maaakso
Share one project context across ChatGPT, Claude, Telegram and any MCP client.
Knowledge & Memory Note Taking
1

Related MCP Servers

Herald
kOlapsis
A
license
Not graded
quality
C
maintenance
The self-hosted MCP bridge between Claude Chat and Claude Code.
Updated 3 months ago (2026-06-09 11:54 UTC)
46
AGPL 3.0
memorix
Knowledge & Memory Developer Tools Autonomous Agents
AVIDS2
A
license
A
quality
A
maintenance
Cross-agent memory bridge for AI coding assistants. Persistent knowledge graph shared across 10 IDEs (Cursor, Windsurf, Claude Code, Codex, Copilot, Kiro, Antigravity, OpenCode, Trae, Gemini CLI) via MCP. 22 tools including team collaboration, auto-cleanup, mini-skills, session management, and workspace sync. 100% local, zero API keys required.
Updated 8 hours ago (2026-09-06 10:07 UTC)
9
1,884
730
Apache 2.0
mcacp
Coding Agents Agent Orchestration Autonomous Agents
Oortonaut
A
license
A
quality
D
maintenance
Bridges any MCP client (like Claude Code, Zed, VS Code) to any ACP coding agent, enabling multi-agent orchestration from a single chat interface.
Updated 7 months ago (2026-02-01 05:08 UTC)
24
210
9
Apache 2.0
cursor-agent-mcp
Developer Tools Code Analysis AI & Machine Learning
HermesVC
A
license
Not graded
quality
C
maintenance
MCP bridge from OpenCode to Cursor agent CLI, enabling code review, debugging, and planning via Cursor cloud.
Updated 2 months ago (2026-06-30 16:04 UTC)
22
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sena-labs/OzBridge'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

OzBridge — Warp Oz for any IDE or agent, via MCP

What is OzBridge?

Feature gallery

Runs & Resources

Warp Drive

MCP bridge

Dashboard

Table of Contents

Features

Requirements

Installation

From a registry

From VSIX (local)

From source

Verify the installation

Connect your MCP client

How do I use Warp Oz in Claude Code?

How do I use Warp Oz in Cursor?

How do I use Warp Oz in Codex CLI?

How do I use Warp Oz in VS Code?

Usage

Chat Participant (@oz)

Slash Commands

/history filters

/schedule sub-commands

Agent Mode — Language Model Tools

Sidebar & Status Bar

Prompt variables

Hand off to Warp

Tools

Configuration

Per-workspace overrides (.warp/warp-bridge.yaml)

Architecture

Folder structure

Data flow

Development

Test Suite

Contributing

Troubleshooting

oz command not found

Authentication errors

Timeout errors

Extension not activating

FAQ

License

Disclaimer

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Chat Participant (`@oz`)

`/history` filters

`/schedule` sub-commands

Per-workspace overrides (`.warp/warp-bridge.yaml`)

`oz` command not found