opencode-bridge

opencode_start

Delegates an easy or medium task to an opencode agent asynchronously and returns a task id; refuses hard or unsure work and prompts with secrets, then enforces the routing mode.

Instructions

Delegate an EASY or MEDIUM job to an opencode agent (async; returns a task id). POLICY IS ENFORCED: tier is required and hard/unsure work is refused (it stays on Claude); the routing MODE (blueprint default | sensitive | insensitive; sensitive wins) is detected from env OPENCODE_MODE, /.claude/sensitive|insensitive, ~/.claude/insensitive, or the mode argument, and limits the agents (sensitive: explorer, librarian, deep-research, oracle, and fixer/worker only with mechanical:true). Blueprint mode: give fixer/designer a written Blueprint (files, signatures, edge cases, acceptance criteria, test command). Prompts containing secrets are refused. The session is titled "/: ". LIMITS: at most OPENCODE_BRIDGE_MAX_PARALLEL tasks at once (default 6), a per-task timeout, automatic retry (backoff) of transient provider errors for read-only agents only, prompts over ~100 KB are sent as an attached file. Verify the result yourself - it is an untrusted draft. Call opencode_policy for the full rules.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "prompt": "<prompt>",
      "tier": "<tier>"
    },
    "name": "opencode_start"
  }
}

Input Schema

Name	Required	Description
`cwd`	No	Directory inside the allowed root
`lane`	No	Lane / project short name for the session title (capitals), default = cwd name
`mode`	No	blueprint \| sensitive \| insensitive - only when the user asked for a mode; sensitive always wins over other sources
`tier`	Yes	easy \| medium (delegable) \| hard \| unsure (refused: stays on Claude)
`agent`	No	opencode agent: explorer \| librarian \| deep-research \| oracle \| fixer \| designer \| general \| worker (default: explorer in sensitive mode, otherwise worker)
`model`	No	provider/model[#variant]; default opencode's own default (set OPENCODE_BRIDGE_MODEL to change)
`title`	No	Full session title; overrides the generated "<lane>/<agent>: <task>" (keep the convention)
`prompt`	Yes	Full task: context, absolute paths, desired output, test command; the agent has no memory of this conversation
`session`	No	Previous task id to continue its session
`mechanical`	No	sensitive mode only: true = strictly mechanical boilerplate / text replacement
`timeout_minutes`	No	wall-clock limit, default 120 (1-1440); the process group is killed when it is reached

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.0Nov 12, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: async execution with task id, tier policy enforcement, mode detection sources and precedence, secrets refusal, parallelism limits (default 6), per-task timeout, retry behavior for read-only agents only, and the ~100 KB prompt-to-file fallback. It also warns that results are untrusted drafts to be verified.

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

Conciseness3/5

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

The core action and the tier policy are front-loaded, but the body is a dense run-on sentence packing mode detection paths, limits, and retry rules together. The information is valuable, yet the structure makes it hard to scan and would benefit from separation.

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 an 11-parameter, no-annotation, async delegation tool, the description covers policy enforcement, routing precedence, concurrency and timeout limits, retry scope, prompt size handling, and result trust. It is complete enough for an agent to invoke it correctly without reading separate documentation.

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 is 100%, so the baseline is 3, but the description adds real meaning on top: tier semantics (easy/medium delegable vs hard/unsure refused), how the mode is detected and resolved with sensitive precedence, sensitive-mode agent restrictions with mechanical:true, and the default agent per mode. Only cwd, lane, and title get little elaboration 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 opens with a specific verb+resource: delegate an EASY or MEDIUM job to an opencode agent, async with a task id. It distinguishes itself from siblings (opencode_policy, opencode_result) by naming the routing policy and pointing to opencode_policy for full rules.

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 states when to use it (easy/medium delegable work) and when not (hard/unsure is refused and stays on Claude). It names alternatives and tells the agent to call opencode_policy for the full rules, and explains what to give fixer/designer in blueprint mode.

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

Deploy Server