Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@open-delegate refactor the utils module with opencode"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Delegate a Cursor task to a real, unattended background OpenCode agent — cheaper model, isolated history — through five small MCP tools.
Goal | Detail |
Reduce Cursor spend | Hand work to cheaper OpenCode alternatives (Zen free, open-weights, mid/cheap OpenRouter) |
Real OpenCode handoff | Cursor "delegates" like the native tool, but OpenCode executes |
Trivial install | Finds the |
Guarded model policy | MCP-level default / force catalog / allow / deny; soft always-on routing rule |
Guarded lifecycle | Bounded waits, no leaked background processes, real error text |
Live preview | Each session returns its own |
Related MCP server: cursor-mcp-bridge
Supporting IDEs other than Cursor
Chasing Anthropic/OpenAI flagship quality (Opus / Sonnet / Fable / GPT Sol / Terra are out of curated defaults)
Cursor slug → OpenCode remapping
Task-kind / persona auto-routing beyond configurable force / allow / deny lists
Replacing the native delegate tool for Cursor-native models not on the force list
Cursor (this plugin is Cursor-only).
Node.js ≥ 18.17 (nodejs.org or your package manager).
OpenCode CLI on your PATH (or set OPEN_DELEGATE_OPENCODE_BIN to its full path).
Pick one (package name on npm is opencode-ai, not opencode):
macOS / Linux
# Recommended one-liner
curl -fsSL https://opencode.ai/install | bash
# Or via npm
npm i -g opencode-ai@latest
# Or Homebrew (tap stays more up to date than the official formula)
brew install anomalyco/tap/opencodeWindows
npm i -g opencode-ai@latest
# Or Scoop / Chocolatey
scoop install opencode
# choco install opencodeVerify:
opencode --versionOpenCode needs at least one usable model. Either:
Run opencode auth login (or /connect inside the OpenCode TUI) and add a provider API key, or
Use a free hosted model such as opencode/deepseek-v4-flash-free (no API key required for that path).
Docs: opencode.ai/docs.
Note:
@verbalize/open-delegateis not yet published on npm, and the Cursor Marketplace listing is pending. Until then, install from a git clone (below), which registers a local Cursor plugin pointed at your build.
git clone git@github.com:Verbalize-public/open-delegate.git
cd open-delegate
npm install
npm run build
npm run register:localThen Cursor → Developer: Reload Window. Customize → MCP Tools should list open-delegate with five tools: ode_delegate, ode_await, ode_transcript, ode_cancel, ode_diagnostics.
register:local syncs the plugin into ~/.cursor/plugins/local/open-delegate with an mcp.json that runs node <checkout>/dist/index.cjs (avoids the npx 404 while the package is unpublished), and registers a workspaceOpen hook so Cursor loads that path. Re-run after moving the repo, pulling changes, or editing src/ (rebuild first).
Edit the installed ~/.cursor/plugins/local/open-delegate/mcp.json (keep the absolute args path the sync wrote):
{
"mcpServers": {
"open-delegate": {
"command": "node",
"args": ["/absolute/path/to/open-delegate/dist/index.cjs"],
"env": {
"OPEN_DELEGATE_DEFAULT_MODEL": "opencode/deepseek-v4-flash-free"
}
}
}
}On Windows the args path looks like C:/Users/<you>/…/open-delegate/dist/index.cjs (forward slashes are fine).
Optional lists (CSV): OPEN_DELEGATE_ODE_MODELS, OPEN_DELEGATE_ALLOW_MODELS, OPEN_DELEGATE_DENY_MODELS.
For a large custom force list, prefer OPEN_DELEGATE_ODE_MODELS_FILE (JSON array or CSV path) over a giant env CSV.
For a full OpenCode config blob (advanced), use OPEN_DELEGATE_OPENCODE_CONFIG_CONTENT instead.
Full env reference: skills/ode-delegate/reference/config.md.
Cursor (MCP client)
│ stdio, JSON-RPC
▼
open-delegate MCP server (this repo → dist/index.cjs)
│ spawns + owns
▼
opencode serve (1 shared default runtime)
│ HTTP via OpenCode's client SDK
▼
model / providerSoft rule rules/open-delegate-routing.mdc: if the named model is on ODE_MODELS or is openrouter/…, use ode_delegate + ode_await (not native Task).
The default opencode serve runtime is pre-warmed right after MCP connect, so most ode_delegate calls hit an already-warm process.
ode_delegate returns a stable sessionId within a few seconds — status: "running" if setup already finished, or status: "starting" if it's still finishing in the background; poll with ode_await (timeoutMs: 0 for a single peek). Optional waitMs can finish short tasks in one call. Pass sessionId to resume a finished session.
Before starting a prompt, models are checked against the live OpenCode provider.list() snapshot (fail-fast MODEL_NOT_AVAILABLE).
Prompts are capped at ~512KiB inline; use promptPath for anything larger.
ode_await polls OpenCode's /session/status + message list — never the MCP server's own say-so alone.
If opencode serve crashes, every session pinned to it is marked "error" immediately (no hang).
Closing the MCP connection disposes every spawned opencode serve process.
Internal events are logged as one-line JSON to stderr and to a PID-named file; ode_diagnostics reads them back live — see config.md and errors.md.
Doc | Topic |
Agent-facing contract: when/how to use the five tools | |
Cheap force-set pins / job defaults | |
Tool-by-tool input/output | |
| |
Error shapes | |
Soft always-on routing (ODE_MODELS / openrouter → ODE) | |
Cost-first catalog research | |
Local development, testing, project layout, release gate | |
Diagnose host-side connection errors, find logs by pid |
Issues and PRs welcome. See CONTRIBUTING.md for local setup, tests, project layout, and the maintainer release gate.
Hit a "Connection stopped"/timeout in Cursor, or need to find an opencode process's log by pid? See RUNBOOK.md.
Blocks (up to a clamped timeout) until the session started by ode_delegate finishes, then returns its final status (plus a capped answer when text is available). While still running, may include currentActivity (e.g. tool:bash … or thinking). Pass timeoutMs: 0 for a single non-blocking status check. Returns status:"running"/"starting" if the timeout elapses first — call again to keep waiting.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Session id returned by ode_delegate. | |
| timeoutMs | No | How long to wait before returning (clamped to 0-120000ms; default 30000ms). Pass 0 for a single non-blocking status check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses blocking behavior, clamped timeout, return on timeout, currentActivity field, and status values. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with main purpose, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description explains return fields (status, answer, currentActivity) and possible statuses ('running'/'starting'). Complete for a blocking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), but description adds clamping range (0-120000ms) and default for timeoutMs, going beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool awaits a delegated OpenCode session until completion, returning final status and optional answer. It differentiates from sibling ode_delegate by referencing it as the session starter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (after ode_delegate) and provides usage details like passing timeoutMs=0 for non-blocking check. Lacks explicit when-not-to-use, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aborts an in-progress session started by ode_delegate. A no-op (still returns ok) if it already finished.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Session id returned by ode_delegate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the no-op behavior for finished sessions but does not mention if the operation is destructive or any side effects like session cleanup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. First sentence states primary purpose, second adds critical no-op detail. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides essential context. Could be improved by mentioning return format or side effects, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description does not add meaning beyond what the schema already provides ('Session id returned by ode_delegate'). Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'aborts' and resource 'in-progress session', explicitly distinguishes from ode_delegate which starts the session. Also notes the no-op behavior for already finished sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates when to use (to abort an in-progress session started by ode_delegate). Lacks explicit exclusions or alternatives like ode_await for waiting, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Starts a new OpenCode agent session to work on prompt (or promptPath) in the background and returns a sessionId - typically with status "running" once the underlying opencode server is warm, or "starting" if it just had to cold-spawn (never blocks past a few seconds either way, unless waitMs is set). Pass sessionId to resume a finished session with a follow-up prompt. Follow up with ode_await (block until done or timeout; timeoutMs: 0 = single check).
Model policy (cost-first):
default (when model omitted): opencode/deepseek-v4-flash-free
ODE_MODELS force-routing catalog: opencode/deepseek-v4-flash-free, opencode/nemotron-3-ultra-free, opencode/mimo-v2.5-free, opencode/laguna-s-2.1-free, … (13 total)
allow list: openrouter/, opencode/ (default)
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory for the delegated session. Omit to use the server's own cwd. | |
| agent | No | OpenCode agent/mode name to run as. Omit for opencode's own default. Ignored when resuming. | |
| model | No | Model as "provider/model", e.g. "opencode/deepseek-v4-flash-free". Omit to use OPEN_DELEGATE_DEFAULT_MODEL or the OpenCode server default. Ignored when resuming via sessionId. | |
| title | No | Optional short title for the session (shown in opencode's own session list). Ignored when resuming. | |
| prompt | No | The task/instructions to hand off (inline). Mutually exclusive with promptPath; one is required. Hard cap ~512KiB — use promptPath for anything larger. When sessionId is set, this is the follow-up prompt. | |
| waitMs | No | After setup succeeds, block up to this many ms for the session to finish (clamped 0-60000). Omitting skips the wait (same as waitMs: 0). Useful for short tasks that can finish in one tool call. | |
| sessionId | No | Resume an existing terminal session with a follow-up prompt instead of creating a new one. Session must not be running/starting. | |
| promptPath | No | Absolute path to a UTF-8 text file containing the prompt, for anything too large to inline safely (~512KiB cap applies to the file too). Mutually exclusive with prompt. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes typical status ('running' or 'starting'), cold-spawn behavior, non-blocking nature unless waitMs set, model routing policy, and cost-first default. No annotations provided, so description fully carries behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with sections, but slightly verbose. Each part adds value, but could be slightly more concise. Front-loaded with main action and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description covers usage, behavior, model policy, and parameter constraints thoroughly. Includes return value and session lifecycle, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds significant context beyond schema: mutual exclusivity of prompt and promptPath, 512KiB cap, waitMs clamping, resume conditions, and model format guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a new OpenCode agent session to work on a prompt and returns a sessionId, with specific verb 'Starts' and resource 'OpenCode agent session'. It distinguishes from siblings by mentioning follow-up with ode_await and the session lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (delegating a task), when to omit (resume with sessionId), and alternatives (ode_await for blocking). Covers mutual exclusivity of prompt/promptPath, model selection, and cost policy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only snapshot of the open-delegate MCP bridge itself (not a specific session): its own pid/version/log paths, every live opencode runtime with its own pid/url/log path, recent internal events, and session counts by status. Use this to diagnose host-side "Connection stopped" / "Timed out waiting for connection" errors, or to find which opencode process/log backs a given runtimeKey.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares it is 'read-only' and lists what information is returned, but does not detail performance characteristics or rate limits. Since no annotations are provided, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences front-load all critical information (purpose, scope, contents) and then provide usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return contents well (pid, version, logs, etc.). It lacks specifics on format, but covers the breadth sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so baseline is 4. The description adds no param information, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a read-only snapshot of the bridge itself, listing specific outputs (pid, version, log paths, runtimes, events, session counts). It distinguishes itself from sibling tools that operate on sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: to diagnose host-side connection errors or to find which process/log backs a runtimeKey. It implies not for session-specific diagnostics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches the conversation so far for a session started by ode_delegate, without waiting for it to finish.
| Name | Required | Description | Default |
|---|---|---|---|
| tail | No | Only return the last N messages (default 20; 0 for all). | |
| sessionId | Yes | Session id returned by ode_delegate. | |
| includeToolCalls | No | When true, append a truncated one-liner per tool call under each assistant message. Default false (text-only). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It clearly states that the tool is non-blocking ('without waiting for it to finish') and returns the current conversation. It does not mention error behavior or side effects, but for a simple read operation, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that includes the core functionality and key constraint ('without waiting for it to finish'). No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 parameters, all described in schema) and no output schema, the description covers the essential behavior. However, it misses hinting at the return format, which would improve completeness. Minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the tool description adds no extra meaning beyond what the schema already provides for the three parameters (sessionId, tail, includeToolCalls). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state that this tool fetches the transcript of a delegated OpenCode session without waiting for it to finish. The verb 'Fetches' and resource 'conversation so far' are specific, and it distinguishes from siblings like ode_delegate and ode_await.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it is for sessions started by ode_delegate and that it returns the conversation without blocking, implying it is useful for reading ongoing sessions. However, it does not explicitly state when to use alternatives like ode_await or ode_cancel, though sibling names provide implicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0-alphaode_awaitode_cancelode_delegateode_diagnosticsode_transcriptEach of the five tools has a clearly distinct purpose: starting a session, waiting for completion, fetching transcript, canceling, and diagnostics. There is no overlap or ambiguity.
All tools share the 'ode_' prefix and mostly use imperative verbs (delegate, await, cancel), but 'transcript' is a noun, breaking the pattern slightly. Overall consistent.
Five tools are well-scoped for managing agent sessions: start, wait, fetch transcript, cancel, and diagnostics. Neither too few nor too many.
The set covers core session lifecycle (start, wait, cancel, transcript), but lacks a tool to list session IDs explicitly. Diagnostics provides session counts but not individual IDs, a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Task management your AI agents can actually run. One line becomes a context-ready task over MCP.
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
Remote data science agents for Snowflake, Databricks & BigQuery in Claude/Cursor via MCP
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Verbalize-public/open-delegate'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
