Codexがコーディング作業をOpenCodeに委任できるようにする、ローカルで動作する小さなMCP（Model Context Protocol）サーバーです。公式のMCP Python SDK、stdioトランスポート、非同期のOpenCodeサブプロセスを利用します。
opencode_executeopencode_execute(
task: str,
working_directory: str,
model: str | None = None,
reasoning_effort: str | None = None,
timeout: int = 1800,
)このコマンドをシェルなしで実行します：
opencode run --format json --dir <working_directory> --auto [--model <model>] [--variant <reasoning_effort>] <task>reasoning_effortは、OpenCodeのプロバイダー固有の--variantオプションに対応します。一般的な値にはminimal、low、medium、high、maxなどがありますが、利用可能なバリアントは選択したプロバイダーとモデルによって定義されます。MCPサーバーは、プロバイダー固有のenumを強制せず、意図的に空でない任意の値を受け入れます。
例：
opencode_execute(
task="Implement uncertainty propagation and run the unit tests.",
working_directory="C:\\path\\to\\NuSR",
model="pinche_10/gpt-5.6-sol",
reasoning_effort="high",
timeout=1800,
)次の内容を含む構造化された出力を返します：
成功、タイムアウト、終了コード、経過時間
OpenCodeのセッションIDと最終的なアシスタントの要約
完了したOpenCodeのツール呼び出しとエラー
上限付きのstdout/stderrキャプチャ
最終的なgit status --short、git diff --stat、および上限付きのunified diff
Gitフィールドは実行後のスナップショットです。この呼び出しの前にすでに存在していた変更が含まれることもあります。未追跡ファイルのテキスト内容は新規ファイルのパッチとして表現され、バイナリの未追跡ファイルはパスとサイズで報告されます。
opencode_check設定されたOpenCode実行可能ファイルを特定し、環境を変更せずにopencode --versionを実行します。
Related MCP server: BoundedRelay
要件：Python 3.11以上、Git（diffレポート用にオプション）、OpenCode。
git clone https://github.com/TAO-MINGYU/codex_to_opencode.git
cd codex_to_opencode
uv venv --python 3.11 .venv
uv pip install --python .venv\Scripts\python.exe -e ".[dev]"OpenCodeは個別にインストールされ、認証されている必要があります。まず確認してください：
opencode --version
opencode auth listOpenCodeデスクトップアプリケーションとOpenCode CLIは、Windows上では別々のエントリポイントです。GUIを開いて何も出力しないOpenCode.exe --versionの実行は、CLIとして利用できません。必要になった場合は、公式CLIをインストールしてください：
npm install -g opencode-aiopencodeがPATHにない場合は、OPENCODE_MCP_COMMANDに実行ファイルの絶対パスを設定してください。Windowsのnpmインストールでは、node_modules\opencode-ai\bin\opencode.exeにあるネイティブバイナリを推奨します。サーバーはopencode.cmdラッパーも自動的に検出してバイパスします。
設定を手編集しなくて済むように、Codex CLIでサーバーを追加します：
codex mcp add opencode --env OPENCODE_MCP_COMMAND=C:\path\to\opencode.exe -- C:\path\to\opencode-mcp\.venv\Scripts\python.exe -m opencode_mcp.serverOpenCodeがすでにPATHにある場合は、--envオプションを省略します：
codex mcp add opencode -- C:\path\to\opencode-mcp\.venv\Scripts\python.exe -m opencode_mcp.serverその後、登録を確認します：
codex mcp listMCP設定を変更した後は、Codexを再起動してください。このサーバーは、stdio MCPサーバーに要求されるように、プロトコルメッセージをstdoutにのみ書き込み、ログをstderrに送信します。
環境変数 | デフォルト | プロセッサ |
|
| 実行可能ファイル名または絶対パス |
|
| 実行可能ファイルの後に挿入されるJSON配列（ラッパーやテストに便利） |
|
| OpenCodeの |
|
| stdout/stderrのそれぞれに保持される末尾バイト数 |
|
| stderrに書き込まれるサーバーログレベル |
自動承認をfalseに設定すると、OpenCodeは対話的に確認できない権限を拒否します：
$env:OPENCODE_MCP_AUTO_APPROVE = "false"自動テストを実行します：
.venv\Scripts\python.exe -m pytest --cov=opencode_mcp --cov-fail-under=80
.venv\Scripts\python.exe -m ruff check .
.venv\Scripts\python.exe -m ruff format --check .MCP Inspectorでサーバーを実行します：
uv run --python 3.11 --with-editable ".[dev]" mcp dev src\opencode_mcp\server.pyMCPツールのタイムアウトは、opencode_executeに渡すtimeoutよりわずかに長く設定してください。そうしないと、サーバーがOpenCodeを終了して診断情報を返す前に、CodexがMCPリクエストをキャンセルしてしまう可能性があります。
opencode_executeは、意図的に書き込みが可能で、破壊的な可能性があるツールです。このMCPサーバーと同じファイルシステムとプロセスの権限をOpenCodeに付与します。実装では以下のことを行います：
OpenCodeのタスクのためにシェルを起動しない
作業ディレクトリとして、存在する絶対パスを要求する
キャプチャする出力を制限してCodexのコンテキストを保護する
タイムアウトまたはMCPのキャンセル時にOpenCodeのプロセスツリーを終了させる
委任された実行中はOpenCodeの自動更新を無効にする
MCPツールを非冪等かつ潜在的に破壊的なものとしてマークする
信頼できないタスクやリポジトリを委任する場合は、制限されたOSアカウントまたはサンドボックスを使用してください。
Resolve the configured OpenCode executable and report its version.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| error | Yes | |
| command | Yes | |
| version | Yes | |
| available | Yes | |
| resolved_executable | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds behavioral detail beyond those annotations by stating the tool resolves a configured executable, which implies reading configuration and locating a binary. No contradiction with annotations.
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?
A single, front-loaded sentence states the key action and outcome, with no filler or redundant detail. Every word earns its space.
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?
The tool has no parameters, a complete annotation set, and an output schema, so the description only needs to convey the high-level purpose and behavior. It does so completely for this simple check operation.
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 the baseline is 4. The description does not need to explain any parameters, and the schema fully covers them.
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 uses a specific verb-resource pair: 'Resolve the configured OpenCode executable and report its version.' It clearly identifies both the action and the subject, and the title reinforces the purpose. It is also easily distinguishable from the sibling tool opencode_execute, which implies running commands rather than checking the installation.
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 implies a clear context: this is a verification or preflight check of the local OpenCode installation, distinct from execution. While it does not explicitly cite when-or-when-not to use it relative to opencode_execute, the 'check' framing and resolved-executable behavior provide clear usage context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delegate one repository coding task to OpenCode.
OpenCode runs non-interactively in the supplied directory, may read and modify files, execute terminal commands, run tests, and use Git. The result contains OpenCode's final text, observed tool calls, diagnostics, and the final Git working-tree diff. The Git diff is a post-run snapshot and can include changes that existed before this call.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Complete coding task and acceptance criteria for OpenCode. | |
| model | No | Optional OpenCode model in provider/model form; omit for its configured default. | |
| timeout | No | Maximum execution time in seconds (default 1800). | |
| reasoning_effort | No | Optional provider-specific reasoning effort passed to OpenCode as --variant, for example minimal, low, medium, high, or max. | |
| working_directory | Yes | Absolute path to the existing project directory OpenCode may modify. |
| Name | Required | Description |
|---|---|---|
| model | Yes | |
| errors | Yes | |
| stderr | Yes | |
| stdout | Yes | |
| success | Yes | |
| summary | Yes | |
| git_diff | Yes | |
| exit_code | Yes | |
| timed_out | Yes | |
| git_status | Yes | |
| session_id | Yes | |
| git_diff_stat | Yes | |
| elapsed_seconds | Yes | |
| output_truncated | Yes | |
| reasoning_effort | Yes | |
| tool_invocations | Yes | |
| working_directory | Yes | |
| git_diff_truncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior over the annotations (destructiveHint=true, readOnlyHint=false) by disclosing non-interactive execution, possible file modifications, CLI/Git actions, and execution of tests. It also warns that the returned Git diff is a post-run snapshot and may include pre-existing changes. This is useful, though it does not enumerate every destructive action or limitation.
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 focused: one purpose-driven opening sentence followed by a terse but information-dense paragraph about behavior and result shape. Every sentence earns its place, including the important Git-diff caveat. The length is appropriate for the tool's complexity.
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?
With a complete input schema and an output schema present, the description covers the main operational ambiguity: non-interactive execution, mutation of files, and the non-isolated nature of the Git diff. It is mostly complete, but it leaves the distinction versus opencode_check unstated, and it does not describe interaction between the timeout/model parameters and the result.
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 the parameter descriptions in the schema already carry the meaning for task, working_directory, model, timeout, and reasoning_effort. The tool description does not add extra parameter syntax, examples, or semantic clarifications beyond what the schema provides.
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 immediately states a specific operation: delegating one repository coding task to OpenCode, and enumerates what the tool can do (read/modify files, run commands, tests, Git). It is clear, but it does not explicitly contrast with the sibling tool opencode_check, so it stops short of full differentiation.
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 first sentence implies the usage: delegate a coding task to OpenCode. The description also clarifies that it runs non-interactively in a repository, which helps the agent set expectations. However, there is no explicit 'when not to use' or comparison with the sibling opencode_check; usage guidance is present but largely implicit.
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.
v0.1.0opencode_checkopencode_executeScored across 2 tools
The two tools have clearly distinct roles: opencode_execute delegates a coding task, while opencode_check resolves the executable and reports its version. There is no realistic confusion between performing an action and checking the installation.
Both tools use the same opencode_ prefix followed by a concise imperative verb, maintaining a consistent snake_case pattern. Though the prefix is a product name, the convention is uniform and predictable.
Two tools is at the low end of typical server scope and feels thin for a coding integration. However, the narrow focus on delegating a single task plus a health check is reasonable enough to be borderline appropriate.
The server covers its core purpose: opencode_execute handles task delegation, and opencode_check verifies the underlying executable. Obvious lifecycle tools such as cancellation or querying current task status are absent, but they fall outside the stated minimal purpose.
Use your Mac, Windows or Linux computer from ChatGPT, Claude or Codex: files, commands, documents.
Work on your own computers from Claude or ChatGPT: run commands, edit and search files.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
