What can you do with this server?

This server is a thin MCP bridge that lets Codex Desktop plan and dispatch coding tasks to a locally-running OpenCode agent within your current project directory. It provides: * Configure the bridge: Set default model, session reuse duration (1–168 hours), and cleanup interval (1–365 days) via opencode.configure. No API keys or project paths are stored. * Run coding tasks: Send concise instructions with opencode.run (synchronous returns output quickly or provides a recoverable taskId; asynchronous returns a durable taskId immediately). Supports reusing recent sessions, resuming a specific session, and enabling OpenCode background subagents. * Long-running tasks: opencode.run_task creates durable tasks recoverable after MCP restarts, requiring MCP task support. * Manage sessions: List, cancel, delete, or clean expired sessions. Active and child sessions are protected. Shut down idle bridge-owned OpenCode servers. * Handle permissions: Inspect and respond to native permission requests (allow once/always or reject) for operations like edit, bash, or webfetch. * Project‑local execution: OpenCode reads the current project directly; no project paths need to be passed.

How do I use codex-mcp-opencode?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@codex-mcp-opencode refactor the user model to use async/await" 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.

codex-mcp-opencode

by Ichikawashadow

Overview Schema Related Servers Score Discussions

TypeScript

Local

codex-mcp-opencode

中文 | English

A project-local MCP bridge: Codex plans; OpenCode executes in the project.
项目内 MCP 桥接器：Codex 负责规划，OpenCode 在项目内执行。

Codex Desktop  ->  codex-mcp-opencode  ->  OpenCode Server/SDK  ->  Current project
    planning          thin control plane       sessions/models         code and tools

中文说明

它解决什么问题

codex-mcp-opencode 让 Codex Desktop 作为项目的规划者和调度者，而 OpenCode 作为实际执行者。Codex 只需向 OpenCode 下达简短、具体的工作指令；OpenCode 从启动它的当前项目目录中自行读取代码、配置和已有上下文。

它不是第二个项目记忆系统，也不是 API Key 管理器，更不会向模型重复发送源码或项目摘要。模型、供应商和凭据始终由 OpenCode 自己管理。

核心特性

能力	说明
项目天然隔离	MCP 从当前项目目录启动，不接受 `project_path` 一类参数。
短期会话复用	默认复用 24 小时内、同模型且空闲的主会话，减少重复加载上下文。
生命周期管理	可列出、取消、删除、清理过期会话；不会自动删除活动会话或子会话。
原生后台子代理	只使用 OpenCode 的后台 subagent 能力，不实现 worktree 或外部并行替代。
MCP 长任务	通过 `opencode.task` 启动、查询、短连接等待或取消；任务本身无桥接器时限，不依赖宿主协商实验性 MCP Tasks。
跨会话恢复	每个项目复用一个本地、脱离 MCP 进程的 OpenCode server；异步任务 ID 和 server 端点均持久化，新的 MCP 进程可继续查询结果。
原生压缩	使用 OpenCode 的 token 统计；复用会话的估算上下文达到 550k 时，请求 OpenCode 原生摘要，以便在 600k 前完成压缩。
保守权限	OpenCode 以 `ask` 权限启动；独立监视器持久化原生权限请求，可经 MCP 查询和响应。

前置条件

Node.js 20 或更高版本。
opencode 已安装并在 PATH 中可用，或通过 OPENCODE_BIN 指向其可执行文件；模型和凭据仍只在 OpenCode 内配置。
OpenCode 中必须开启原生压缩和裁剪：compaction.auto: true、compaction.prune: true。

桥接器使用 OpenCode 实际上报的模型上下文上限，不再要求所有供应商都伪装为同一个数值。对复用会话，它在下一次提示前检查 OpenCode 最近一次报告的上下文估算（输入 + 缓存读取 + 输出）；达到 550k 时调用 OpenCode 原生摘要，目标是在 550k–600k 窗口内完成压缩。模型压缩策略仍完全由 OpenCode 配置管理。

通用的 OpenCode 配置形状如下：

{
  "compaction": { "auto": true, "prune": true }
}

给其他用户的安装与接入

本仓库当前可直接从 GitHub 安装，尚未发布到 npm。使用者不需要修改源码、填写 API Key，也不需要在工具调用中提供项目路径。

方式一：直接在 Codex MCP 配置中使用 GitHub（推荐）

将以下命令配置为 Codex 的 stdio MCP 服务：

command: npx
args:    --yes github:Ichikawashadow/codex-mcp-opencode

Codex 必须从当前打开的目标项目目录启动该命令。npx 从 GitHub 获取包时会运行 prepare 自动构建；之后 OpenCode 仍由 MCP 在当前项目内拉起。

方式二：克隆后本地安装

git clone https://github.com/Ichikawashadow/codex-mcp-opencode.git
cd codex-mcp-opencode
npm ci
npm run build

然后将下面的程序配置为 Codex 的 stdio MCP 服务：

command: node
args:    <安装目录>/dist/index.js

这里的 <安装目录> 是 MCP 自身的本机安装位置，不是目标项目路径。它只应存在于用户自己的 Codex 配置中，不能写进本仓库、代码或工具参数。

无论选哪种方式，都要确认：

opencode --version

能正常运行，并且 OpenCode 已在其自己的配置中完成模型/API 配置。

首次使用时：

调用 opencode.configure，不传参数。
从返回的模型列表中选择一个可用的 <provider-id>/<model-id>。
再次调用 opencode.configure，将它作为 defaultModel。
使用 opencode.run 向 OpenCode 发送简短工作指令。

日常使用时，Codex 可先调用 opencode.sessions 查看近期会话，再用 opencode.run 复用会话或启动新工作。opencode.run(asynchronous: true) 会返回持久 taskId；普通 opencode.run 若在 20 秒内完成则直接返回输出，若仍在执行会返回 accepted，若触发原生审批会返回 input_required，两者均携带可恢复的 taskId。对超过五分钟、半小时或数小时的工作，建议直接用 opencode.task 的 start。两种方式都可在新的 MCP 进程中用 status 或 wait 取回结果。任务开始后的 30 秒内建议每 2 秒查询一次，以便立即显示审批；之后前 10 分钟每 60 秒查询一次，随后每 5 分钟一次。wait 的 1-240 秒仅是单次 RPC 的安全窗口。取消会先拒绝该任务未回复的权限、再中止会话，且终态后桥接器不会再回传其输出。需要并行时，传入 backgroundSubagents: true；它只会启用 OpenCode 原生后台子代理。

工具参考

工具	何时使用
`opencode.configure`	首次配置、查看 OpenCode 可用模型、设置默认模型和复用/清理周期。
`opencode.run`	正常执行任务；设 `asynchronous: true` 时返回可跨 MCP 会话恢复的 `taskId`。
`opencode.task`	长任务管理：`start` 立即返回任务 ID 与建议查询间隔，`status` 查询，`wait` 仅进行最多 240 秒的单次 RPC 等待，`cancel` 取消。任务本身可持续数小时。
`opencode.sessions`	`list`、`cancel`、`delete`、`cleanup`，或用 `permissions` / `respond_permission` 处理原生授权；`shutdown_server` 仅关闭无活动任务且由桥接器启动的 server。

会话和权限

本地注册表按工作目录隔离，只保存会话 ID、父会话 ID、模型 ID、时间戳及活动任务 ID。它不保存提示词、代码、Diff、日志、模型输出、路径、密钥或项目摘要。OpenCode 才是会话历史与输出的唯一来源。

标准 MCP 无法把 Codex Desktop 的实时逐命令审批状态传给服务器，因此无法承诺完全相同的动态权限。桥接器采取更严格的下限：edit、bash、webfetch、external_directory 和 doom_loop 均为 ask。当 OpenCode 请求操作许可时，用 opencode.sessions 查看并显式响应。

OpenCode server 为跨 MCP 会话恢复而保持脱离 stdio 运行。若需要移动或删除工作目录，请先确保没有活动 bridge task，再调用 opencode.sessions(action: "shutdown_server")；它只会终止由该桥接器显式记录为 managed 的 server，不会终止用户配置的外部 server 或旧版未标记 server。

开发

npm test
npm run build
npm pack --dry-run

要对本机 OpenCode 和 MCP stdio 传输做显式集成验证（会消耗一次模型调用），在 PowerShell 中运行：

$env:OPENCODE_E2E = '1'
npm run test:e2e

Related MCP server: opencode-chatgpt-bridge

English

What it is for

codex-mcp-opencode makes Codex Desktop the planner and dispatcher for a project, while OpenCode is the execution agent. Codex sends short, specific work instructions; OpenCode reads code, configuration, and existing context directly from the project directory in which it was launched.

This is not a second project-memory system or an API-key manager. It never sends source trees or broad project summaries back through the bridge. Providers, models, and credentials remain entirely in OpenCode.

Key capabilities

Capability	Behavior
Project-local by default	The MCP starts in the current project directory and has no `project_path` argument.
Short-lived session reuse	By default, an idle primary session using the same model is reused for 24 hours.
Session lifecycle	List, cancel, delete, and clean expired sessions without automatically deleting active or child sessions.
Native background subagents	Uses only OpenCode background subagents; there is no worktree or external-parallel fallback.
Long-running tasks	`opencode.task` starts, checks, bounded-waits for, and cancels work without depending on experimental MCP Task negotiation. The task itself has no bridge-imposed duration limit.
Cross-session recovery	Each project reuses a local OpenCode server detached from the MCP process; async task IDs and the server endpoint are persisted so a new MCP process can retrieve results.
Native compaction	The bridge uses OpenCode token accounting and requests native summarization at 550k estimated context, keeping compaction ahead of 600k.
Conservative permissions	OpenCode starts with `ask` permissions; a detached monitor persists native permission requests for MCP inspection and response.

Prerequisites

Node.js 20 or later.
opencode available on PATH, or its executable supplied through OPENCODE_BIN; models and credentials remain configured in OpenCode.
Native OpenCode compaction enabled: compaction.auto: true and compaction.prune: true.

The bridge uses the context limit reported by OpenCode and does not require every provider to advertise an artificial common value. Before resuming a session, it checks OpenCode's latest estimated context (input + cache read + output) and requests native summarization at 550k, so compaction occurs within the 550k-600k window. Model compaction policy remains entirely in OpenCode configuration.

Use this portable OpenCode configuration shape:

{
  "compaction": { "auto": true, "prune": true }
}

Installation and connection for other users

This repository can currently be installed directly from GitHub; it has not been published to npm. Users do not need to edit source code, enter API keys, or provide project paths in tool calls.

Option 1: use GitHub directly in Codex MCP configuration (recommended)

Configure this command as a Codex stdio MCP server:

command: npx
args:    --yes github:Ichikawashadow/codex-mcp-opencode

Codex must start the command from the currently opened target project directory. When npx obtains the package from GitHub it runs prepare to build it; the MCP still starts OpenCode inside the current project.

Option 2: clone and install locally

git clone https://github.com/Ichikawashadow/codex-mcp-opencode.git
cd codex-mcp-opencode
npm ci
npm run build

Then configure this program as a Codex stdio MCP server:

command: node
args:    <installation-directory>/dist/index.js

<installation-directory> is the user's local MCP installation, not the target project path. It belongs only in the user's Codex configuration, never in this repository, source code, or tool arguments.

With either option, confirm that:

opencode --version

works and that OpenCode has its own model/API configuration.

First use:

Call opencode.configure with no arguments.
Select an available OpenCode model from the returned list.
Call opencode.configure again with that <provider-id>/<model-id> as defaultModel.
Use opencode.run to send short work instructions to OpenCode.

For daily work, Codex can call opencode.sessions to inspect recent sessions and then call opencode.run to reuse a session or start fresh work. opencode.run(asynchronous: true) returns a durable taskId; a normal opencode.run returns direct output when it completes within 20 seconds, otherwise returns accepted, and returns input_required when native approval is needed. Both non-completed cases include a recoverable taskId. For work that may take more than five minutes, half an hour, or several hours, prefer opencode.task with start. Either form can be recovered from a new MCP process with status or wait. Poll every 2 seconds for the first 30 seconds to surface approval promptly, every 60 seconds for the rest of the first 10 minutes, and every 5 minutes thereafter; a 1-240 second wait is only a safe single-RPC window. Cancellation rejects unresolved permissions before aborting the session, and the bridge never returns output for a cancelled task. For parallel work, pass backgroundSubagents: true; this only enables OpenCode native background subagents.

Tool reference

Tool	When to use it
`opencode.configure`	First-time setup, model discovery, and default model/reuse/cleanup settings.
`opencode.run`	Normal task execution; with `asynchronous: true`, returns a `taskId` recoverable across MCP sessions.
`opencode.task`	Long-running work: `start` returns a task ID and recommended poll interval immediately; `status` checks it; `wait` uses only a safe single-RPC window of up to 240 seconds; `cancel` stops it. The task can run for hours.
`opencode.sessions`	Use `list`, `cancel`, `delete`, or `cleanup`; use `permissions` and `respond_permission` for native authorization requests; `shutdown_server` stops an idle bridge-owned server only.

Sessions and permissions

The small local registry is isolated by launch directory. It stores only session IDs, parent session IDs, model IDs, timestamps, and active task IDs. It never stores prompts, code, diffs, logs, model output, paths, keys, or project summaries. OpenCode is the single source of truth for session history and output.

Standard MCP does not expose Codex Desktop's live per-command approval state to servers, so exact dynamic permission mirroring is impossible. The bridge takes the stricter floor: edit, bash, webfetch, external_directory, and doom_loop all start as ask. Use opencode.sessions to inspect and explicitly answer OpenCode permission requests.

The OpenCode server intentionally outlives stdio so tasks can recover across MCP calls. Before moving or removing a workspace, ensure there are no active bridge tasks and call opencode.sessions(action: "shutdown_server"). It terminates only a server explicitly recorded as bridge-managed; it never terminates a user-configured external server or an older unmarked runtime.

Development

npm test
npm run build
npm pack --dry-run

To explicitly test local OpenCode and the MCP stdio transport (this makes one model call), run in PowerShell:

$env:OPENCODE_E2E = '1'
npm run test:e2e

Available Tools

4 tools

opencode.configureConfigure OpenCode bridgeC

Lists OpenCode models and stores only bridge defaults. It never stores provider keys or edits project paths.

ParametersJSON Schema

Name	Required	Description	Default
`reuseHours`	No
`cleanupDays`	No
`defaultModel`	No

TDQS

C2.7/5.0

Behavior3/5

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

With no annotations, the description adds value by disclosing that the tool does not store provider keys or edit project paths. However, it does not cover other behavioral aspects such as side effects, authentication needs, or response format. The claim of listing models is unqualified.

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 very concise with two sentences, avoiding fluff. However, it could be structured better with bullet points or a clearer separation of functionality and constraints.

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

Completeness2/5

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

For a configuration tool with 3 undocumented parameters and no output schema, the description is too sparse. It does not explain how results are returned, how to properly use parameters, or what constitutes valid input. The agent lacks sufficient context to use the tool effectively.

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

Parameters1/5

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

Schema description coverage is 0%, and the tool description provides no explanation of the parameters (reuseHours, cleanupDays, defaultModel). The agent must guess their purpose from names alone, which is insufficient for correct invocation.

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

Purpose4/5

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

Description clearly states the tool lists OpenCode models and stores bridge defaults, and explicitly mentions what it does not do (store keys, edit paths). However, it does not explicitly distinguish from sibling tools like opencode.run or opencode.sessions, though the configuration purpose is inferred.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description lacks context like prerequisites, typical use cases, or explicit recommendations. It only states what the tool does and does not do.

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

opencode.runRun an OpenCode coding taskB

Destructive

Creates or resumes a project-local OpenCode session and executes a concise task. This may edit the current project.

ParametersJSON Schema

Name	Required	Description
`task`	Yes	A concise implementation instruction. OpenCode reads the current project itself.
`model`	No	An existing OpenCode provider/model ID.
`reuse`	No	Reuse a recent compatible primary session; defaults to true.
`sessionId`	No	An existing OpenCode session ID to resume.
`asynchronous`	No	Return after OpenCode accepts the task; use sessions to inspect or cancel it.
`backgroundSubagents`	No	Allow only OpenCode native background subagents for independent work.

Output Schema

ParametersJSON Schema

Name	Required	Description
`async`	Yes
`output`	No
`reused`	Yes
`status`	Yes
`modelId`	No
`sessionId`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that it may edit the project, but does not disclose other behavioral traits like authentication, rate limits, or what happens to existing sessions.

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 that are direct and front-loaded. Every word is essential, no redundancy.

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

Completeness3/5

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

Adequate given the output schema exists and parameters are documented. However, could provide more context about asynchronous behavior or integration with other tools.

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 the schema already documents all parameters. The description adds minimal context about the 'task' parameter (reads project itself), but no significant value beyond the schema.

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

Purpose4/5

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

The description clearly states it creates/resumes a session and executes a task, possibly editing the project. However, it does not differentiate from the sibling tool opencode.run_task, which likely has similar functionality.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives like opencode.run_task or opencode.sessions. The description does not specify prerequisites or exclusions.

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

opencode.run_taskRun OpenCode as an MCP TaskA

Destructive

Starts a durable OpenCode task when the MCP host negotiates task support. The task is recovered from the OpenCode session after MCP restart.

ParametersJSON Schema

Name	Required	Description
`task`	Yes	A concise implementation instruction. OpenCode reads the current project itself.
`model`	No	An existing OpenCode provider/model ID.
`reuse`	No	Reuse a recent compatible primary session; defaults to true.
`sessionId`	No	An existing OpenCode session ID to resume.
`backgroundSubagents`	No	Allow only OpenCode native background subagents for independent work.

Output Schema

ParametersJSON Schema

Name	Required	Description
`async`	Yes
`output`	No
`reused`	Yes
`status`	Yes
`modelId`	No
`sessionId`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already indicate destructive behavior; description adds value by disclosing durability and recovery after restart, which are not in annotations.

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 with front-loaded purpose and efficient addition of recovery detail, no wasted 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?

Given rich schema descriptions and annotations, the description covers core behavior adequately; could slightly improve by noting what happens when task support is not negotiated.

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 descriptions cover all 5 parameters clearly; the tool description adds no additional parameter context beyond what the schema provides.

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 starts a durable OpenCode task and recovers after restart, distinguishing it from sibling tools like opencode.run (non-durable) and opencode.configure (configuration).

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?

The description implies usage when durable task execution with recovery is needed, and mentions the condition of MCP host negotiating task support, but lacks explicit when-not-to-use or alternative sibling comparisons.

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

opencode.sessionsManage OpenCode sessionsB

Destructive

Lists, cancels, deletes, or cleans expired bridge-managed OpenCode sessions. Active and child sessions are protected from deletion.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`sessionId`	No
`permissionId`	No
`permissionResponse`	No

TDQS

B3/5.0

Behavior3/5

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

Annotations already indicate destructiveness (destructiveHint=true), so the bar is lower. The description adds that active and child sessions are protected, which is useful safety context. However, it does not disclose other behavioral traits like authorization requirements, rate limits, or what happens to related data. Score 3 acknowledges the added value without being comprehensive.

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 two sentences: the first lists the actions concisely, the second adds a key constraint. Every word earns its place, and the most important information (what the tool does) is front-loaded. There is no redundancy or verbosity.

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

Completeness2/5

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

Given the tool has 4 parameters with 0% schema coverage, multiple actions, and no output schema, the description is insufficient. It does not explain the role of permission-related parameters, how actions are selected, or the expected return values. An agent would struggle to use all functionality correctly without additional context.

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

Parameters2/5

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

Schema coverage is 0%, so the description carries the full burden. It mentions the action types ('list', 'cancel', etc.) but does not explain the meaning of 'sessionId', 'permissionId', or 'permissionResponse' parameters beyond what the enum values suggest. The mapping from actions to required parameters is missing, making it hard for an agent to invoke correctly.

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

Purpose4/5

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

The description clearly lists the actions (list, cancel, delete, clean) and the resource (OpenCode sessions), making the tool's purpose apparent. However, it does not explain the difference between similar actions like 'cancel' and 'delete', nor does it distinguish this tool from its siblings (opencode.configure, opencode.run, opencode.run_task). A higher score would require explicit differentiation.

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

Usage Guidelines2/5

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

The description offers no guidance on when to use this tool versus alternatives, nor does it specify prerequisites or exclusions. The only usage hint is that active/child sessions are protected from deletion, but this is a constraint, not a usage guideline. A score of 2 reflects the lack of actionable context for choosing this tool.

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.

4 tool updatesv0.1.0Jul 30, 2026
- First observedopencode.configure
- First observedopencode.run
- First observedopencode.run_task
- First observedopencode.sessions

Install Server

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

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose: configure handles defaults and model listing, run executes one-off tasks, run_task manages durable tasks, and sessions manages session lifecycle. No overlap.

Naming Consistency4/5

All tools use the 'opencode.' prefix and are lower case, but 'run_task' uses an underscore while others are single words, introducing minor inconsistency.

Tool Count5/5

With 4 tools, the set is well-scoped for managing OpenCode sessions and tasks—neither too few nor too many.

Completeness4/5

Covers core operations (configure, run, durable run, session management). Minor gaps like explicit task output retrieval or model listing beyond configure are present but not critical.

Maintenance

ActivitySlowing

ResponsivenessNo issues

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

agentmailrooms-mcp
com.clauxel.agentmailrooms
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
Agent Orchestration Autonomous Agents
2
ContexterOAuth
io.github.maaakso
Share one project context across ChatGPT, Claude, Telegram and any MCP client.
Knowledge & Memory Note Taking
1
SprintraOAuth
io.github.Sprintra-io
The project brain for AI coding agents — memory, decisions, sprints, knowledge base via MCP.
Project Management Developer Tools Knowledge & Memory
23
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

codex-agy-bridge
Agent Orchestration Autonomous Agents
varadfromeast
A
license
B
quality
A
maintenance
An MCP bridge that lets Codex delegate long-running agent work to the Antigravity CLI, providing observable and resumable tool-based execution with project scoping.
Updated 2 months ago (2026-07-20 17:58 UTC)
13
7
MIT
opencode-chatgpt-bridge
Coding Agents Developer Tools Version Control
yuga-hashimoto
A
license
Not graded
quality
B
maintenance
A local MCP bridge that lets ChatGPT control opencode sessions for code modification, file reading, and repository management on your own computer.
Updated 3 months ago (2026-06-17 16:05 UTC)
1
MIT
codex-chatgpt-bridge
File Systems Code Execution Developer Tools
Dalomeve
A
license
Not graded
quality
B
maintenance
Local MCP bridge enabling ChatGPT web to access approved local files and execute tasks via local Codex.
Updated 2 months ago (2026-06-27 05:46 UTC)
6
MIT
codex-mcp
File Systems Code Analysis Shell Access
larrynutzagger-glitch
A
license
Not graded
quality
B
maintenance
Remote MCP coding bridge that gives ChatGPT/Codex secure local workspace access, including file retrieval, semantic code intelligence, Git, diagnostics, and guarded shell execution.
Updated a month ago (2026-08-08 22:34 UTC)
30
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/Ichikawashadow/codex-mcp-opencode'

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