A minimal MCP server that wraps qodercli (Qoder CLI), letting any MCP client delegate coding tasks to a local Qoder agent.
シンプルな MCP server で、ローカルの qodercli（Qoder CLI）を MCP ツールとしてラップし、任意の MCP クライアント（Qoder IDE、Claude Code、Cursor など）がサブエージェントのように Qoder を呼び出せるようにします。
Some CLI agents ship an official MCP server mode (e.g. codex mcp-server), but qodercli currently only acts as an MCP client. This project fills that gap with a thin wrapper: it spawns qodercli -p <prompt> under the hood and streams the result back over MCP stdio.
一部の CLI Agent は公式の MCP server モードを提供しています（例：codex mcp-server）が、qodercli は現在 MCP クライアントとしてのみ機能します。このプロジェクトは薄いラッパーでそのギャップを埋めます：内部で qodercli -p <prompt> を起動し、結果を MCP stdio を介してストリーム返します。
Related MCP server: github-copilot-cli-mcp-server
ask-qoder tool — delegate a prompt to qodercli
ask-qoder ツール —— タスクを qodercli に委任する
Structured output (session_id, is_error, duration_ms, total_credits, num_turns) via -o json parsing
構造化出力（session_id、is_error、duration_ms、total_credits、num_turns）、-o json を自動解析
list-sessions tool to discover resumable sessions
list-sessions ツール、再開可能なセッションを発見する
list-models tool for runtime model discovery (no stale model lists)
list-models ツール、実行時に利用可能なモデルを発見（古いリストに依存しない）
reasoning_effort parameter (--reasoning-effort)
reasoning_effort パラメータ（--reasoning-effort を透過）
Server instructions in the MCP initialize result guide clients on usage
MCP initialize 結果にサーバー使用説明が含まれ、クライアントの正しい呼び出しを導く
Codex-style sandbox levels (read-only / workspace-write / danger-full-access)
codex スタイルの sandbox レベル（read-only / workspace-write / danger-full-access）
System prompt injection (system_prompt / append_system_prompt)
システムプロンプト注入（system_prompt / append_system_prompt）
Working directory, model, permission mode, output format control
作業ディレクトリ、モデル、権限モード、出力フォーマットの指定をサポート
Session resume (resume_session_id) for multi-turn delegation
セッション再開（resume_session_id）をサポートし、マルチターン委任が可能
Timeout protection with SIGKILL fallback
タイムアウト保護（タイムアウト時に自動 SIGKILL）
Proxy quota support (HTTP_PROXY / HTTPS_PROXY injection)
プロキシクォータサポート（HTTP_PROXY / HTTPS_PROXY の注入）
Zero build step — plain ESM JavaScript, Node.js >= 18
ビルド不要 —— プレーンな ESM JavaScript、Node.js >= 18
Node.js >= 18
qodercli installed and signed in (qodercli login)
Option A — npx (recommended / 推奨): no clone needed, the MCP client downloads the package on first use. クローン不要、MCP クライアントが初回使用時に自動ダウンロード：
"command": "npx", "args": ["-y", "qodercli-mcp"]Option B — from source (for development / 開発用):
git clone https://github.com/cantbeblank96/qodercli-mcp.git
cd qodercli-mcp
npm installAdd to ~/.qoder/mcp.json. Prefer the absolute path of node and set QODERCLI_PATH explicitly (nvm-managed binaries are often missing from the PATH seen by MCP child processes):
Proxy Support: To use your Qoder CLI proxy quota, add
HTTP_PROXYand/orHTTPS_PROXYto the server's environment. When these are set at the MCP server level, they will be passed to all qodercli subprocesses.
~/.qoder/mcp.json に追加します。node の絶対パスを使用し、QODERCLI_PATH を明示的に設定することを推奨します（MCP 子プロセスの PATH には nvm 管理のバイナリがしばしば含まれていません）：
プロキシサポート：Qoder CLI プロキシクォータを使用するには、サーバーの環境変数に
HTTP_PROXYおよび/またはHTTPS_PROXYを追加します。これらの変数が MCP サーバーレベルで設定されると、すべての qodercli 子プロセスに渡されます。
{
"mcpServers": {
"qodercli-mcp": {
"command": "npx",
"args": ["-y", "qodercli-mcp"],
"env": {
"QODERCLI_PATH": "/absolute/path/to/qodercli",
"PATH": "/usr/local/bin:/usr/bin:/bin"
}
},
"qodercli-mcp-with-proxy": {
"command": "npx",
"args": ["-y", "qodercli-mcp"],
"env": {
"QODERCLI_PATH": "/absolute/path/to/qodercli",
"HTTP_PROXY": "http://127.0.0.1:39900",
"HTTPS_PROXY": "http://127.0.0.1:39900",
"PATH": "/usr/local/bin:/usr/bin:/bin"
}
}
}
}Developers running a local checkout instead of the published package (Option B) should replace command/args with the absolute node path and /path/to/qodercli-mcp/src/index.js (nvm-managed node is often missing from the PATH seen by MCP child processes).
ローカルソース（方式 B）を使用する開発者は、command/args を node の絶対パスと /path/to/qodercli-mcp/src/index.js に置き換えてください（MCP 子プロセスの PATH には nvm 管理のバイナリがしばしば含まれていません）。
{
"mcpServers": {
"qodercli-mcp": {
"command": "node",
"args": ["/absolute/path/to/qodercli-mcp/src/index.js"],
"env": {
"QODERCLI_PATH": "/absolute/path/to/qodercli"
}
}
}
}ask-qoderParameter | Type | Description |
| string (required) | The task or question for qodercli / qodercli に渡すタスクまたは質問 |
| string | Working directory / 作業ディレクトリ |
| string | Model for this session; call |
| string | Reasoning effort level ( |
| enum |
|
| enum | codex-style: |
| enum |
|
| string | Replace the default system prompt / デフォルトのシステムプロンプトを置き換える |
| string | Append instructions to the default system prompt / システムプロンプトを追加 |
| string | Resume a previous session / 以前のセッションを再開 |
| string | Passed to |
| string[] | Raw CLI args appended before the prompt; reserved flags (permission mode, system prompt, model, |
| number | Timeout in ms, default 600000 / タイムアウト（ミリ秒）、デフォルト 600000 |
ask-qoder declares an MCP outputSchema and returns, in addition to the human-readable text, a structuredContent object:
ask-qoder は MCP outputSchema を宣言し、人間が読めるテキストに加えて structuredContent オブジェクトを返します：
{
"session_id": "77826b5c-...", // pass back as resume_session_id / 回传用于续接
"content": "OK",
"is_error": false,
"exit_code": 0,
"duration_ms": 1280,
"total_credits": 0.53,
"num_turns": 1,
"timed_out": false,
"truncated": false
}sandbox | Effective permission mode / 実際の権限モード | Effect on qodercli / qodercli への効果 |
(omitted / 省略) |
| Read-only: permission-requiring tools are silently denied / 読み取り専用：権限が必要なツール呼び出しは静かに拒否される |
|
| Plus |
|
| Agent can create/modify files in |
|
| Full access including shell / 完全なアクセス（シェル含む） |
Explicit permission_mode or approval_policy always wins over sandbox.
明示的に設定された permission_mode / approval_policy は sandbox より優先されます。
Mode | Behavior / 動作 |
| Read-only: silently denies every tool call that requires permission. Headless-safe default / 読み取り専用：権限が必要なすべてのツール呼び出しを静かに拒否。ヘッドレスセーフなデフォルト |
| Auto-approves file edits; shell still governed by policy / ファイル編集を自動承認 |
| Auto-approves everything including shell / すべてを自動承認（シェル含む） |
| qodercli's own automatic policy / qodercli の自動ポリシー |
| Interactive confirmation — not headless-friendly, avoid in MCP calls / 対話的な確認 — ヘッドレスに不向き、MCP 呼び出しでは避ける |
list-sessionsLists local qodercli sessions (index, summary, session id) so a client can pick a resume_session_id. Takes no arguments.
ローカルの qodercli セッション（インデックス、サマリー、セッション ID）を一覧表示し、resume_session_id を選択しやすくします。引数なし。
list-modelsLists models currently supported by qodercli (via --list-models), so a client can pick a valid model value at runtime instead of relying on stale knowledge. Returns both a text list and a structured models array. Takes no arguments.
qodercli が現在サポートしているモデルを一覧表示し、実行時に有効な model 値を選択できるようにします（古い知識に依存しない）。テキストリストと構造化された models 配列を返します。引数なし。
{ "name": "ask-qoder", "arguments": {
"prompt": "Explain what main.py does",
"cwd": "/path/to/project",
"timeout_ms": 180000
}}結果は自然言語の説明を返し、ファイルの機能を理解するのに役立ちます。
{ "name": "ask-qoder", "arguments": {
"prompt": "@src/service.py Review this file for security issues and suggest improvements",
"model": "qwen-plus",
"permission_mode": "dont_ask",
"timeout_ms": 300000
}}Qoder はセキュリティアドバイスと改善案を提供します。
// First call — session_id comes back in structuredContent
// 首次调用 —— session_id 会在 structuredContent 中返回
{ "name": "ask-qoder", "arguments": {
"prompt": "Help me refactor this module to improve readability",
"cwd": "/projects/backend",
"timeout_ms": 300000
}}
// Then reuse structuredContent.session_id:
// 然后把 structuredContent.session_id 回传：
{ "name": "ask-qoder", "arguments": {
"prompt": "Now add error handling for database timeouts",
"resume_session_id": "77826b5c-cd6b-4213-b423-d95b4e1deab0"
}}
// Or discover ids with list-sessions / 或用 list-sessions 查找历史会话 ID
{ "name": "list-sessions", "arguments": {} }resume_session_id を使用することで、マルチターンの対話型反復最適化が可能です。
{ "name": "ask-qoder", "arguments": {
"prompt": "Analyze performance bottlenecks in utils.py",
"model": "qwen-max",
"permission_mode": "default",
"output_format": "text",
"timeout_ms": 240000
}}パフォーマンス分析や最適化提案のシナリオに適しています。
{ "name": "ask-qoder", "arguments": {
"prompt": "Audit this codebase for security issues; do not modify anything",
"cwd": "/workspaces/repo",
"sandbox": "read-only",
"timeout_ms": 300000
}}read-only はファイル書き込みとシェルツールを無効にし、監査/レビューシナリオに適しています。
{ "name": "ask-qoder", "arguments": {
"prompt": "Summarize the architecture of this project and identify key modules",
"cwd": "/workspaces/repo",
"timeout_ms": 420000,
"model": "qwen-plus"
}}大規模プロジェクトの迅速な整理とアーキテクチャ理解に適しています。
Specify working directory — Always pass cwd when operating on a specific project
操作特定项目时务必指定 cwd
Use timeout protection — For complex prompts, set explicit timeout_ms shorter than 60min
複雑なタスクには timeout_ms（5～10 分推奨）を設定し、ハングアップを防ぐ
Resume for multi-turn — Chain follow-ups via resume_session_id instead of repeating context
後続の質問は resume_session_id でセッションを継続し、コンテキストの重複を避ける
Model selection — Call list-models first to discover currently supported models; larger models are better for deep analysis
先に list-models を呼び出して現在利用可能なモデルを確認する。深い分析には大規模モデルを推奨
Permission mode — The server default is read-only (dont_ask); set QODERCLI_DEFAULT_PERMISSION_MODE=bypass_permissions to make full (YOLO) access the default for personal deployments. Per-call: tasks that must create/modify files need sandbox: "workspace-write"; shell access needs danger-full-access. Do not combine sandbox with an explicit permission_mode (the latter wins)
サーバーのデフォルトは読み取り専用（dont_ask）。個人デプロイでは QODERCLI_DEFAULT_PERMISSION_MODE=bypass_permissions を設定してフルアクセス（YOLO）をデフォルトにできる。呼び出しごと：ファイル作成・変更が必要なタスクは sandbox: "workspace-write"、シェルアクセスが必要な場合は danger-full-access を設定。sandbox と明示的な permission_mode は併用不可（後者が優先）
Variable | Default | Description |
|
| Path to the qodercli binary / qodercli バイナリのパス |
|
| Default timeout / デフォルトのタイムアウト |
|
| Per-call stdout/stderr cap in MB (OOM protection) / 呼び出しごとの出力上限（MB、OOM 対策） |
|
| Default permission mode when the caller omits permission_mode/approval_policy/sandbox; set |
| - | HTTP proxy URL for qodercli / qodercli の HTTP プロキシ URL |
| - | HTTPS proxy URL for qodercli / qodercli の HTTPS プロキシ URL |
npm test # smoke test: protocol handshake + tool invocation
node src/index.js # run the server manually (stdio)This is an unofficial, third-party tool. It is not affiliated with, endorsed, or sponsored by Qoder. Use permission_mode: bypass_permissions with care — delegated prompts may modify files in the target working directory.
本ツールは非公式のサードパーティ製であり、Qoder とは提携・承認・支援関係にありません。bypass_permissions 権限モードは注意して使用してください。委任されたプロンプトは対象の作業ディレクトリ内のファイルを変更する可能性があります。
MIT
Delegate a task to qodercli (Qoder CLI), a local agentic coding assistant. Use it to get a second opinion, a code review, or to have Qoder perform a self-contained coding task in a given working directory. Returns structured output including session_id; pass it back as resume_session_id to continue the conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory for qodercli (project to operate on). | |
| model | No | Model to use for this session (e.g. 'Auto', 'Ultimate', 'Qwen3.8-Max', 'Kimi-K3'). Call the list-models tool first to get the currently supported model names. | |
| prompt | Yes | The task or question for qodercli. | |
| sandbox | No | Sandbox level, codex-style: read-only = dont_ask + blocked write/shell tools; workspace-write = accept_edits (agent can create/modify files in cwd); danger-full-access = bypass_permissions. Ignored when permission_mode or approval_policy is set. Default (when omitted) is read-only. | |
| extra_args | No | Additional raw CLI arguments appended before the prompt. Flags with dedicated parameters (permission mode, system prompt, model, output format, resume, cwd) are rejected. | |
| timeout_ms | No | Timeout in ms (default: 600000). | |
| output_format | No | CLI output format passed to -o (default: json). | |
| system_prompt | No | Replace qodercli's default system prompt for this call. | |
| approval_policy | No | codex-style approval policy: untrusted->dont_ask (read-only), on-request->auto, never->bypass_permissions. Mutually exclusive with permission_mode. | |
| permission_mode | No | Permission mode (default: dont_ask). dont_ask = READ-ONLY (silently denies edits/shell); accept_edits = auto-approve file edits; bypass_permissions = full access incl. shell; auto = qodercli's automatic policy. Mutually exclusive with approval_policy; prefer the sandbox parameter instead. | |
| reasoning_effort | No | Reasoning effort level passed to --reasoning-effort (e.g. 'low', 'medium', 'high'); supported levels depend on the selected model. | |
| resume_session_id | No | Resume a previous qodercli session by its identifier. | |
| append_system_prompt | No | Append extra instructions to the default system prompt. |
| Name | Required | Description |
|---|---|---|
| content | Yes | The assistant's final answer. |
| is_error | Yes | |
| exit_code | No | |
| num_turns | No | |
| timed_out | Yes | |
| truncated | Yes | |
| session_id | No | qodercli session id for follow-ups. |
| duration_ms | No | |
| total_credits | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description explains it delegates to a local coding assistant and returns session_id for resumption, but does not disclose potential side effects like file modifications or shell access, leaving that to schema parameter descriptions.
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?
Three concise sentences that front-load the core action, use cases, and the session/resume flow; 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?
For a 13-parameter tool with output schema, the description provides the essential high-level context (delegation, use cases, resume flow) but could mention prerequisites like listing models first; schema compensates for parameter details.
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 covers all 13 parameters with descriptions; the description adds no parameter syntax or format details beyond schema, so baseline 3 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?
The description uses a specific verb ('Delegate') and resource ('qodercli'), lists concrete use cases (second opinion, code review, coding task), and clearly distinguishes from sibling tools that list sessions/models.
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?
Clearly explains when to use (second opinion, code review, self-contained coding task) but doesn't mention when not to use or alternatives beyond implicit distinction from list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List models currently supported by qodercli. Use this before picking a model name for ask-qoder.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| models | Yes | Model names as an array. |
| content | Yes | Model names, one per line. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states it lists models but does not disclose any behavioral traits such as read-only nature, authentication, or caching. However, the tool is simple and likely read-only, so the lack of disclosure is not critical but could be improved.
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 concise with two sentences, front-loading the purpose. The second sentence adds clear usage guidance. No fluff.
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 that there are no parameters and the tool is simple, the description is complete enough. It tells the agent what the tool does and when to use it. An output schema is present but not detailed in the description; however, for a list operation, the description is adequate.
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 no parameters, and schema description coverage is 100% (vacuously). The description does not need to add parameter meaning. Baseline for zero parameters is 4, and the description adds no unnecessary information about parameters.
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 what the tool does: 'List models currently supported by qodercli.' It uses a specific verb ('List') and resource ('models supported by qodercli'). It also distinguishes from siblings by noting to use this before picking a model name for ask-qoder, implying ask-qoder is a different action.
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 this tool: 'Use this before picking a model name for ask-qoder.' This gives clear context. It does not explicitly mention when not to use it, but given the tool's singular purpose, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List local qodercli sessions (index + id + summary) so you can pick a resume_session_id for ask-qoder.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It accurately describes a read-only listing operation with no side effects, and adds the context that sessions are 'local' (client-side). For a simple tool with no parameters, this is adequate 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?
The description is a single sentence of 14 words, front-loaded with the action and purpose. Every word earns its place; there is no redundancy or fluff.
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 tool's simplicity (zero parameters, presence of an output schema), the description is fully sufficient. It explains what the tool does, why it is used, and the sibling tools are simple. The output schema covers return values, and the description previews the key fields.
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?
The tool has no parameters, and schema description coverage is trivially 100%. Per the guidelines, zero parameters justifies a baseline score of 4. The description does not need to add parameter information.
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 verb 'list', the resource 'local qodercli sessions', and the specific output fields (index + id + summary). It also explains the purpose: to pick a resume_session_id for ask-qoder, which distinguishes it from its siblings (ask-qoder and list-models).
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 says 'so you can pick a resume_session_id for ask-qoder', which tells the agent when to use this tool (before calling ask-qoder with a session ID). It does not mention when not to use it or provide alternatives, but the context is clear and sufficient for a simple list tool.
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.4.2ask-qoderlist-modelslist-sessionsScored across 3 tools
Each tool has a clearly distinct purpose: ask-qoder for delegating tasks, list-sessions for managing sessions, and list-models for model selection. No overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (ask-qoder, list-sessions, list-models), making them predictable and easy to understand.
Three tools is appropriate for a CLI wrapper MCP server, covering the core interactions (task execution, session management, model listing) without unnecessary bloat.
The tool set covers the essential workflows for qodercli: initiating tasks, resuming sessions, and selecting models. No obvious gaps for its intended purpose.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
MCP server exposing the Backtest360 engine API as tools for AI agents.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
