qodercli-mcp
qodercli-mcp
Ein minimaler MCP-Server, der qodercli (Qoder CLI) umschließt und jedem MCP-Client ermöglicht, Codierungsaufgaben an einen lokalen Qoder-Agenten zu delegieren.
Ein minimaler MCP-Server, der das lokale qodercli (Qoder CLI) als MCP-Tool verpackt, sodass jeder MCP-Client (Qoder IDE, Claude Code, Cursor usw.) Qoder wie einen Unter-Agenten aufrufen kann.
Warum / 为什么
Manche CLI-Agenten bieten einen offiziellen MCP-Server-Modus an (z. B. codex mcp-server), aber qodercli fungiert derzeit nur als MCP-Client. Dieses Projekt schließt diese Lücke mit einem dünnen Wrapper: Es startet qodercli -p <prompt> im Hintergrund und streamt das Ergebnis über MCP stdio zurück.
Einige CLI-Agenten bieten einen offiziellen MCP-Server-Modus (z. B. codex mcp-server), aber qodercli kann derzeit nur als MCP-Client agieren. Dieses Projekt füllt diese Lücke mit einer dünnen Wrapperschicht: Es ruft intern qodercli -p <prompt> auf und gibt das Ergebnis über MCP stdio zurück.
Related MCP server: github-copilot-cli-mcp-server
Funktionen / 功能
ask-qoder-Tool – delegiert eine Eingabeaufforderung an qodercliask-qoder-Tool – delegiert eine Aufgabe an qodercliStrukturierte Ausgabe (
session_id,is_error,duration_ms,total_credits,num_turns) über-o json-ParsingStrukturierte Ausgabe (
session_id,is_error,duration_ms,total_credits,num_turns), automatische Analyse von-o jsonlist-sessions-Tool zum Auffinden fortsetzbarer Sitzungenlist-sessions-Tool zum Auffinden fortsetzbarer Sitzungenlist-models-Tool zur Laufzeit-Modellerkennung (keine veralteten Modelllisten)list-models-Tool zum Erkennen verfügbarer Modelle zur Laufzeit (keine veraltete Liste)reasoning_effort-Parameter (--reasoning-effort)reasoning_effort-Parameter (durchgereicht--reasoning-effort)Server-
instructionsim MCP-Initialisierungsergebnis führen den Client zur NutzungMCP-Initialisierungsergebnis enthält Serveranweisungen, die den Client zur korrekten Nutzung führen
Codex-ähnliche
sandbox-Stufen (read-only/workspace-write/danger-full-access)Codex-ähnliche
sandbox-Stufen (read-only/workspace-write/danger-full-access)System-Prompt-Injektion (
system_prompt/append_system_prompt)System-Prompt-Injektion (
system_prompt/append_system_prompt)Arbeitsverzeichnis, Modell, Berechtigungsmodus, Ausgabeformatsteuerung
Unterstützt Arbeitsverzeichnis, Modell, Berechtigungsmodus, Ausgabeformat
Sitzungsfortsetzung (
resume_session_id) für mehrstufige DelegationUnterstützt Sitzungsfortsetzung (
resume_session_id) für mehrstufige DelegationTimeout-Schutz mit SIGKILL-Fallback
Timeout-Schutz (automatischer SIGKILL bei Timeout)
Proxy-Kontingentunterstützung (
HTTP_PROXY/HTTPS_PROXY-Injektion)Proxy-Kontingentunterstützung (
HTTP_PROXY/HTTPS_PROXY-Injektion)Kein Build-Schritt – reines ESM JavaScript, Node.js >= 18
Kein Build erforderlich – reines ESM JavaScript, Node.js >= 18
Voraussetzungen / 前置条件
Node.js >= 18
qodercliinstalliert und angemeldet (qodercli login)
Installation / 安装
Option A – npx (empfohlen / 推荐): kein Klonen erforderlich, der MCP-Client lädt das Paket bei der ersten Verwendung herunter. Kein Klonen erforderlich, der MCP-Client lädt das Paket bei der ersten Verwendung automatisch herunter:
"command": "npx", "args": ["-y", "qodercli-mcp"]Option B – aus dem Quellcode (für Entwicklung / 开发用):
git clone https://github.com/cantbeblank96/qodercli-mcp.git
cd qodercli-mcp
npm installMCP-Client-Konfiguration / MCP 客户端配置
Qoder IDE
Fügen Sie zu ~/.qoder/mcp.json hinzu. Bevorzugen Sie den absoluten Pfad von node und setzen Sie QODERCLI_PATH explizit (nvm-verwaltete Binärdateien fehlen oft im PATH, der von MCP-Kindprozessen gesehen wird):
Proxy-Unterstützung: Um Ihr Qoder-CLI-Proxy-Kontingent zu nutzen, fügen Sie
HTTP_PROXYund/oderHTTPS_PROXYzur Umgebung des Servers hinzu. Wenn diese auf MCP-Serverebene gesetzt sind, werden sie an alle qodercli-Unterprozesse weitergegeben.
Fügen Sie zu ~/.qoder/mcp.json hinzu. Es wird empfohlen, den absoluten Pfad von node zu verwenden und QODERCLI_PATH explizit zu setzen (im PATH von MCP-Kindprozessen fehlen oft die von nvm verwalteten Binärdateien):
Proxy-Unterstützung: Um Ihr Qoder-CLI-Proxy-Kontingent zu nutzen, können Sie
HTTP_PROXYund/oderHTTPS_PROXYin den Umgebungsvariablen des Servers hinzufügen. Wenn diese Variablen auf MCP-Serverebene gesetzt werden, werden sie an alle qodercli-Unterprozesse weitergegeben.
{
"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"
}
}
}
}Entwickler, die einen lokalen Checkout anstelle des veröffentlichten Pakets verwenden (Option B), sollten command/args durch den absoluten node-Pfad und /path/to/qodercli-mcp/src/index.js ersetzen (nvm-verwaltetes node fehlt oft im PATH, der von MCP-Kindprozessen gesehen wird).
Entwickler, die den lokalen Quellcode anstelle des veröffentlichten Pakets (Option B) verwenden, ersetzen bitte command/args durch den absoluten node-Pfad und /path/to/qodercli-mcp/src/index.js (im PATH der MCP-Kindprozesse fehlt oft das von nvm verwaltete node).
Claude Code / Claude Desktop
{
"mcpServers": {
"qodercli-mcp": {
"command": "node",
"args": ["/absolute/path/to/qodercli-mcp/src/index.js"],
"env": {
"QODERCLI_PATH": "/absolute/path/to/qodercli"
}
}
}
}Tool: ask-qoder
Parameter | Typ | Beschreibung |
| string (erforderlich) | Die Aufgabe oder Frage für qodercli / 交给 qodercli 的任务或问题 |
| string | Arbeitsverzeichnis / 工作目录 |
| string | Modell für diese Sitzung; rufen Sie |
| string | Reasoning-Effort-Stufe ( |
| enum |
|
| enum | codex-artig: |
| enum |
|
| string | Standard-System-Prompt ersetzen / 替换默认系统提示 |
| string | Anweisungen an den Standard-System-Prompt anhängen / 追加系统提示 |
| string | Vorherige Sitzung fortsetzen / 续接之前的会话 |
| string | An |
| string[] | Rohe CLI-Argumente, die vor dem Prompt angehängt werden; reservierte Flags (Berechtigungsmodus, System-Prompt, Modell, |
| number | Timeout in ms, Standard 600000 / 超时毫秒数,默认 600000 |
Strukturierte Ausgabe / 结构化输出
ask-qoder deklariert ein MCP outputSchema und gibt zusätzlich zum
menschenlesbaren Text ein structuredContent-Objekt zurück:
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-Mapping / 沙箱映射
sandbox | Effektiver Berechtigungsmodus / 实际权限模式 | Auswirkung auf qodercli / 对 qodercli 的效果 |
(weggelassen / 缺省) |
| Schreibgeschützt: Berechtigungen erfordernde Tools werden stillschweigend abgelehnt / 只读:需授权的工具调用被静默拒绝 |
|
| Zusätzlich |
|
| Agent kann Dateien in |
|
| Voller Zugriff inklusive Shell / 完全权限(含 shell) |
Explizites permission_mode oder approval_policy hat immer Vorrang vor sandbox.
Explizit gesetztes permission_mode / approval_policy hat Vorrang vor sandbox.
Berechtigungsmodi (verifizierte Semantik) / 权限模式(实测语义)
Modus | Verhalten / 行为 |
| Schreibgeschützt: lehnt jeden Tool-Aufruf, der eine Berechtigung erfordert, stillschweigend ab. Headless-sicherer Standard / 只读:静默拒绝一切需授权的工具调用;无头安全默认值 |
| Dateiänderungen automatisch genehmigen; Shell weiterhin durch Richtlinie geregelt / 自动批准文件编辑 |
| Alles automatisch genehmigen, einschließlich Shell / 全部自动批准(含 shell) |
| qoderclis eigene automatische Richtlinie / qodercli 自动策略 |
| Interaktive Bestätigung – nicht headless-freundlich, in MCP-Aufrufen vermeiden / 交互式确认,无头调用中应避免 |
Tool: list-sessions
Listet lokale qodercli-Sitzungen auf (Index, Zusammenfassung, Sitzungs-ID), sodass ein Client
eine resume_session_id auswählen kann. Erwartet keine Argumente.
Listet lokale qodercli-Sitzungen auf (Index, Zusammenfassung, Sitzungs-ID), damit der Client
eine resume_session_id auswählen kann. Keine Argumente.
Tool: list-models
Listet die derzeit von qodercli unterstützten Modelle auf (über --list-models), sodass ein
Client zur Laufzeit einen gültigen model-Wert auswählen kann, anstatt sich auf
veraltetes Wissen zu verlassen. Gibt sowohl eine Textliste als auch ein strukturiertes models-Array zurück.
Erwartet keine Argumente.
Listet die derzeit von qodercli unterstützten Modelle auf, damit der Client zur Laufzeit
einen gültigen model-Wert auswählen kann (ohne veraltetes Wissen). Gibt eine Textliste und ein strukturiertes models-Array zurück. Keine Argumente.
Anwendungsbeispiele / 使用示例
Beispiel 1: Einfache Code-Erklärung / 简单代码解释
{ "name": "ask-qoder", "arguments": {
"prompt": "Explain what main.py does",
"cwd": "/path/to/project",
"timeout_ms": 180000
}}Das Ergebnis liefert eine Erklärung in natürlicher Sprache, um das Verständnis der Dateifunktion zu unterstützen.
Das Ergebnis gibt eine natürliche Spracherklärung zurück, um das Verständnis der Dateifunktion zu unterstützen.
Beispiel 2: Zweite Meinung einholen / 获取第二意见
{ "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 gibt Sicherheitsempfehlungen und Verbesserungsvorschläge.
Qoder gibt Sicherheitsvorschläge und Verbesserungspläne.
Beispiel 3: Mehrstufige Konversation per Fortsetzung / 多轮对话续接
// 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": {} }Durch resume_session_id können mehrstufige interaktive Iterationen zur Optimierung realisiert werden.
Über resume_session_id können mehrstufige interaktive iterative Optimierungen realisiert werden.
Beispiel 4: Code-Review mit spezifischem Fokus / 针对性代码审查
{ "name": "ask-qoder", "arguments": {
"prompt": "Analyze performance bottlenecks in utils.py",
"model": "qwen-max",
"permission_mode": "default",
"output_format": "text",
"timeout_ms": 240000
}}Geeignet für Szenarien der Leistungsanalyse und Optimierungsvorschläge.
Geeignet für Leistungsanalyse und Optimierungsvorschläge.
Beispiel 5: Schreibgeschützte Analyse / 只读分析
{ "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 deaktiviert Dateischreib- und Shell-Tools, geeignet für Audit-/Review-Szenarien.
read-only deaktiviert Dateischreib- und Shell-Tools, geeignet für Audit-/Review-Szenarien.
Beispiel 6: Projektweite Analyse / 项目范围分析
{ "name": "ask-qoder", "arguments": {
"prompt": "Summarize the architecture of this project and identify key modules",
"cwd": "/workspaces/repo",
"timeout_ms": 420000,
"model": "qwen-plus"
}}Geeignet für schnelle Erfassung und Architekturverständnis großer Projekte.
Geeignet für schnelle Erfassung und Architekturverständnis großer Projekte.
Best Practices / 最佳实践
Specify working directory — Always pass
cwdwhen operating on a specific project 操作特定项目时务必指定cwdUse timeout protection — For complex prompts, set explicit
timeout_msshorter than 60min 复杂任务设置timeout_ms(建议 5–10 分钟),避免挂起Resume for multi-turn — Chain follow-ups via
resume_session_idinstead of repeating context 后续追问用resume_session_id续接会话,避免重复上下文Model selection — Call
list-modelsfirst to discover currently supported models; larger models are better for deep analysis 先调list-models查询当前可用模型;深度分析建议选择大模型Permission mode — The server default is read-only (
dont_ask); setQODERCLI_DEFAULT_PERMISSION_MODE=bypass_permissionsto make full (YOLO) access the default for personal deployments. Per-call: tasks that must create/modify files needsandbox: "workspace-write"; shell access needsdanger-full-access. Do not combinesandboxwith an explicitpermission_mode(the latter wins) 服务器默认只读(dont_ask);个人部署可用QODERCLI_DEFAULT_PERMISSION_MODE=bypass_permissions将全开(YOLO)设为默认。单次调用:需要改文件设sandbox: "workspace-write",需要 shell 用danger-full-access;勿与显式permission_mode混用(后者优先生效)
Environment variables / 环境变量
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 代理地址 |
| - | HTTPS proxy URL for qodercli / qodercli 的 HTTPS 代理地址 |
Development / 开发
npm test # smoke test: protocol handshake + tool invocation
node src/index.js # run the server manually (stdio)Disclaimer / 免责声明
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 权限模式——委托的任务可能修改目标工作目录中的文件。
License
MIT
Available Tools
3 toolsask-qoderA
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. |
Output Schema
| 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 |
TDQS
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-modelsA
List models currently supported by qodercli. Use this before picking a model name for ask-qoder.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| models | Yes | Model names as an array. |
| content | Yes | Model names, one per line. |
TDQS
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-sessionsA
List local qodercli sessions (index + id + summary) so you can pick a resume_session_id for ask-qoder.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| content | Yes |
TDQS
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.4.2- First observed
ask-qoder - First observed
list-models - First observed
list-sessions
TDQS
Scored 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.
Maintenance
Related MCP Connectors
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.
Related MCP Servers
- AlicenseAqualityCmaintenanceLocal MCP server that wraps the headless Claude Code CLI as MCP tools, providing stateless access to Claude's coding capabilities through prompt-based interactions. It enables users to execute Claude Code commands with various prompt formats and structured outputs directly from MCP clients.3MIT
- AlicenseAqualityDmaintenanceWraps GitHub Copilot CLI as an MCP server, enabling MCP clients to run Copilot conversations for code tasks with support for session resumption and permission modes.4MIT
- FlicenseAqualityDmaintenanceProvides a secure interface to run Anthropic's Claude Code CLI as an MCP server, enabling task execution, persistent memory, and integration with MCP-enabled IDEs.12-
- AlicenseAqualityAmaintenanceA local MCP server that delegates coding tasks to a temporary OpenCode session and returns a completion report with changed files, tool calls, cost, and the subagent's reply.1523 npm1MIT