Skip to main content
Glama
cantbeblank96

qodercli-mcp

qodercli-mcp

Un servidor MCP mínimo que envuelve qodercli (Qoder CLI), permitiendo que cualquier cliente MCP delegue tareas de codificación a un agente Qoder local.

Un servidor MCP mínimo que envuelve el qodercli local (Qoder CLI) como herramienta MCP, permitiendo que cualquier cliente MCP (Qoder IDE, Claude Code, Cursor, etc.) invoque a Qoder como si fuera un sub-agente.

Por qué

Algunos agentes CLI incluyen un modo oficial de servidor MCP (por ejemplo, codex mcp-server), pero qodercli actualmente solo actúa como cliente MCP. Este proyecto llena ese vacío con un envoltorio delgado: internamente ejecuta qodercli -p <prompt> y transmite el resultado de vuelta a través de MCP stdio.

Algunos agentes CLI incluyen un modo oficial de servidor MCP (por ejemplo, codex mcp-server), pero qodercli actualmente solo puede actuar como cliente MCP. Este proyecto llena ese vacío con una capa delgada de envoltura: internamente invoca qodercli -p <prompt> y devuelve el resultado a través de MCP stdio.

Related MCP server: github-copilot-cli-mcp-server

Características

  • Herramienta ask-qoder — delega un prompt a qodercli

  • Herramienta ask-qoder — delega tareas a qodercli

  • Salida estructurada (session_id, is_error, duration_ms, total_credits, num_turns) mediante análisis de -o json

  • Salida estructurada (session_id, is_error, duration_ms, total_credits, num_turns), analizada automáticamente desde -o json

  • Herramienta list-sessions para descubrir sesiones reanudables

  • Herramienta list-sessions, para descubrir sesiones que se pueden reanudar

  • Herramienta list-models para descubrimiento de modelos en tiempo de ejecución (sin listas de modelos obsoletas)

  • Herramienta list-models, descubrimiento de modelos disponibles en tiempo de ejecución (no depende de listas obsoletas)

  • Parámetro reasoning_effort (--reasoning-effort)

  • Parámetro reasoning_effort (transparente a --reasoning-effort)

  • Las instructions del servidor en el resultado de inicialización de MCP guían a los clientes sobre su uso

  • Las instrucciones del servidor en el resultado de inicialización de MCP guían al cliente para invocarlo correctamente

  • Niveles de sandbox estilo Codex (read-only / workspace-write / danger-full-access)

  • Niveles de sandbox similares a codex (read-only / workspace-write / danger-full-access)

  • Inyección de prompt del sistema (system_prompt / append_system_prompt)

  • Inyección de prompt del sistema (system_prompt / append_system_prompt)

  • Directorio de trabajo, modelo, modo de permisos, control de formato de salida

  • Soporta especificar directorio de trabajo, modelo, modo de permisos, formato de salida

  • Reanudación de sesión (resume_session_id) para delegación de múltiples turnos

  • Soporta reanudación de sesión (resume_session_id), permitiendo delegación en múltiples rondas

  • Protección de tiempo de espera con fallback SIGKILL

  • Protección de tiempo de espera (SIGKILL automático al exceder el tiempo)

  • Soporte de cuota de proxy (inyección de HTTP_PROXY / HTTPS_PROXY)

  • Soporte de cuota de proxy (inyección de HTTP_PROXY / HTTPS_PROXY)

  • Sin paso de compilación — JavaScript ESM puro, Node.js >= 18

  • Sin necesidad de compilación — JavaScript ESM puro, Node.js >= 18

Prerrequisitos

  1. Node.js >= 18

  2. qodercli instalado y con sesión iniciada (qodercli login)

Instalación

Opción A — npx (recomendada): sin necesidad de clonar, el cliente MCP descarga el paquete en el primer uso. Sin necesidad de clonar, el cliente MCP descarga automáticamente la primera vez que se usa:

"command": "npx", "args": ["-y", "qodercli-mcp"]

Opción B — desde fuente (para desarrollo):

git clone https://github.com/cantbeblank96/qodercli-mcp.git
cd qodercli-mcp
npm install

Configuración del cliente MCP

Qoder IDE

Agregar a ~/.qoder/mcp.json. Preferir la ruta absoluta de node y establecer QODERCLI_PATH explícitamente (los binarios administrados por nvm a menudo faltan en el PATH visto por los procesos hijos de MCP):

Soporte de proxy: Para usar la cuota de proxy de Qoder CLI, agregue HTTP_PROXY y/o HTTPS_PROXY al entorno del servidor. Cuando se establecen a nivel del servidor MCP, se pasarán a todos los subprocesos de qodercli.

Agregar a ~/.qoder/mcp.json. Se recomienda usar la ruta absoluta de node y establecer explícitamente QODERCLI_PATH (el PATH de los procesos hijos de MCP a menudo carece de los directorios binarios administrados por nvm):

Soporte de proxy: Para usar la cuota de proxy de Qoder CLI, puede agregar HTTP_PROXY y/o HTTPS_PROXY en las variables de entorno del servidor. Cuando estas variables se establecen a nivel del servidor MCP, se pasan a todos los subprocesos de 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"
      }
    }
  }
}

Los desarrolladores que ejecuten una copia local en lugar del paquete publicado (Opción B) deben reemplazar command/args con la ruta absoluta de node y /path/to/qodercli-mcp/src/index.js (el node administrado por nvm a menudo falta en el PATH visto por los procesos hijos de MCP). Los desarrolladores que usen el código fuente local (Opción B) deben reemplazar command/args con la ruta absoluta de node y /path/to/qodercli-mcp/src/index.js (el PATH de los procesos hijos de MCP a menudo carece del directorio binario administrado por nvm).

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"
      }
    }
  }
}

Herramienta: ask-qoder

Parámetro

Tipo

Descripción

prompt

string (obligatorio)

La tarea o pregunta para qodercli

cwd

string

Directorio de trabajo

model

string

Modelo para esta sesión; llame a list-models para descubrir nombres disponibles

reasoning_effort

string

Nivel de esfuerzo de razonamiento (--reasoning-effort), p. ej. low/medium/high; depende del modelo

permission_mode

enum

dont_ask (predeterminado, solo lectura) | accept_edits (aprobar automáticamente ediciones de archivos) | bypass_permissions (acceso completo incluyendo shell) | auto | default; mutuamente excluyente con approval_policy, prefiera sandbox

approval_policy

enum

estilo codex: untrusted → solo lectura | on-request → automático | never → acceso completo

sandbox

enum

read-only | workspace-write | danger-full-access (estilo codex; controla el modo de permiso efectivo)

system_prompt

string

Reemplazar el prompt del sistema predeterminado

append_system_prompt

string

Agregar instrucciones al prompt del sistema predeterminado

resume_session_id

string

Reanudar una sesión anterior

output_format

string

Pasado a -o (predeterminado json). Nota: los formatos no json degradan la salida estructurada (session_id etc. quedan no disponibles)

extra_args

string[]

Argumentos CLI sin procesar agregados antes del prompt; las banderas reservadas (modo de permiso, prompt del sistema, modelo, -o, -r, -w...) son rechazadas

timeout_ms

number

Tiempo de espera en ms, predeterminado 600000

Salida estructurada

ask-qoder declara un outputSchema de MCP y devuelve, además del texto legible, un objeto structuredContent:

ask-qoder declara un outputSchema de MCP, además del texto legible, devuelve un objeto 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
}

Mapeo de sandbox

sandbox

Modo de permiso efectivo

Efecto en qodercli

(omitido)

dont_ask

Solo lectura: las herramientas que requieren permiso son silenciosamente denegadas

read-only

dont_ask

Además --disallowed-tools write_file,replace,run_shell_command como defensa en profundidad

workspace-write

accept_edits

El agente puede crear/modificar archivos en cwd

danger-full-access

bypass_permissions

Acceso completo incluyendo shell

permission_mode o approval_policy explícito siempre prevalece sobre sandbox. El permission_mode o approval_policy establecido explícitamente tiene prioridad sobre sandbox.

Modos de permiso (semántica verificada)

Modo

Comportamiento

dont_ask

Solo lectura: deniega silenciosamente cada llamada de herramienta que requiere permiso. Valor predeterminado seguro sin cabeza

accept_edits

Aprueba automáticamente ediciones de archivos; el shell sigue gobernado por la política

bypass_permissions

Aprueba automáticamente todo incluyendo shell

auto

Política automática de qodercli

default

Confirmación interactiva — no apto para entornos sin cabeza, evitar en llamadas MCP

Herramienta: list-sessions

Lista las sesiones locales de qodercli (índice, resumen, id de sesión) para que un cliente pueda elegir un resume_session_id. No toma argumentos.

Lista las sesiones locales de qodercli (número, resumen, ID de sesión), facilitando la selección de resume_session_id. Sin parámetros.

Herramienta: list-models

Lista los modelos actualmente soportados por qodercli (mediante --list-models), para que un cliente pueda elegir un valor model válido en tiempo de ejecución en lugar de basarse en conocimiento obsoleto. Devuelve tanto una lista de texto como un array estructurado models. No toma argumentos.

Lista los modelos actualmente soportados por qodercli, para seleccionar un valor model válido en tiempo de ejecución (no depende de conocimiento obsoleto). Devuelve una lista de texto y un array estructurado models. Sin parámetros.

Ejemplos de uso

Ejemplo 1: Explicación simple de código

{ "name": "ask-qoder", "arguments": { 
  "prompt": "Explain what main.py does",
  "cwd": "/path/to/project",
  "timeout_ms": 180000 
}}

El resultado devuelve una explicación en lenguaje natural que ayuda a entender la función del archivo.

Ejemplo 2: Solicitar una segunda opinión

{ "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 ofrece sugerencias de seguridad y mejoras.

Ejemplo 3: Conversación de múltiples turnos mediante reanudación

// 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": {} }

Mediante resume_session_id se puede lograr una optimización iterativa interactiva de múltiples rondas.

Ejemplo 4: Revisión de código con enfoque específico

{ "name": "ask-qoder", "arguments": {
  "prompt": "Analyze performance bottlenecks in utils.py",
  "model": "qwen-max",
  "permission_mode": "default",
  "output_format": "text",
  "timeout_ms": 240000 
}}

Adecuado para escenarios de análisis de rendimiento y sugerencias de optimización.

Ejemplo 5: Análisis de solo lectura

{ "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 deshabilita herramientas de escritura de archivos y shell, adecuado para escenarios de auditoría/revisión.

Ejemplo 6: Análisis a nivel de proyecto

{ "name": "ask-qoder", "arguments": {
  "prompt": "Summarize the architecture of this project and identify key modules",
  "cwd": "/workspaces/repo",
  "timeout_ms": 420000,
  "model": "qwen-plus"
}}

Adecuado para proyectos grandes para una comprensión rápida de la arquitectura.

Mejores prácticas

  1. Especificar directorio de trabajo — Siempre pasa cwd al operar en un proyecto específico 操作特定项目时务必指定 cwd

  2. Usar protección de tiempo de espera — Para indicaciones complejas, establece un timeout_ms explícito, menor a 60 minutos 复杂任务设置 timeout_ms(建议 5–10 分钟),避免挂起

  3. Reanudar para múltiples turnos — Encadena seguimientos mediante resume_session_id en lugar de repetir el contexto 后续追问用 resume_session_id 续接会话,避免重复上下文

  4. Selección de modelo — Llama primero a list-models para descubrir los modelos actualmente compatibles; los modelos más grandes son mejores para análisis profundos 先调 list-models 查询当前可用模型;深度分析建议选择大模型

  5. Modo de permisos — El valor predeterminado del servidor es solo lectura (dont_ask); establece QODERCLI_DEFAULT_PERMISSION_MODE=bypass_permissions para que el acceso completo (YOLO) sea el predeterminado en despliegues personales. Por llamada: las tareas que deben crear/modificar archivos necesitan sandbox: "workspace-write"; el acceso a shell necesita danger-full-access. No combines sandbox con un permission_mode explícito (este último tiene prioridad) 服务器默认只读(dont_ask);个人部署可用 QODERCLI_DEFAULT_PERMISSION_MODE=bypass_permissions 将全开(YOLO)设为默认。单次调用:需要改文件设 sandbox: "workspace-write",需要 shell 用 danger-full-access;勿与显式 permission_mode 混用(后者优先生效)

Variables de entorno / 环境变量

Variable

Valor predeterminado

Descripción

QODERCLI_PATH

qodercli

Ruta al binario qodercli / qodercli 二进制路径

QODERCLI_TIMEOUT_MS

600000

Tiempo de espera predeterminado / 默认超时

QODERCLI_MAX_OUTPUT_MB

50

Límite de stdout/stderr por llamada en MB (protección OOM) / 单次调用输出上限(MB,防 OOM)

QODERCLI_DEFAULT_PERMISSION_MODE

dont_ask

Modo de permiso predeterminado cuando la persona que llama omite permission_mode/approval_policy/sandbox; establece bypass_permissions para acceso completo (YOLO) / 调用方未指定权限参数时的默认模式;设 bypass_permissions 即全开(YOLO)

HTTP_PROXY

-

URL del proxy HTTP para qodercli / qodercli 的 HTTP 代理地址

HTTPS_PROXY

-

URL del proxy HTTPS para qodercli / qodercli 的 HTTPS 代理地址

Desarrollo / 开发

npm test        # smoke test: protocol handshake + tool invocation
node src/index.js   # run the server manually (stdio)

Descargo de responsabilidad / 免责声明

Esta es una herramienta no oficial de terceros. No está afiliada, respaldada ni patrocinada por Qoder. Usa permission_mode: bypass_permissions con cuidado — las indicaciones delegadas pueden modificar archivos en el directorio de trabajo de destino.

本项目为非官方第三方工具,与 Qoder 官方无关。请谨慎使用 bypass_permissions 权限模式——委托的任务可能修改目标工作目录中的文件。

Licencia

MIT

Available Tools

3 tools
ask-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.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoWorking directory for qodercli (project to operate on).
modelNoModel 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.
promptYesThe task or question for qodercli.
sandboxNoSandbox 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_argsNoAdditional raw CLI arguments appended before the prompt. Flags with dedicated parameters (permission mode, system prompt, model, output format, resume, cwd) are rejected.
timeout_msNoTimeout in ms (default: 600000).
output_formatNoCLI output format passed to -o (default: json).
system_promptNoReplace qodercli's default system prompt for this call.
approval_policyNocodex-style approval policy: untrusted->dont_ask (read-only), on-request->auto, never->bypass_permissions. Mutually exclusive with permission_mode.
permission_modeNoPermission 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_effortNoReasoning effort level passed to --reasoning-effort (e.g. 'low', 'medium', 'high'); supported levels depend on the selected model.
resume_session_idNoResume a previous qodercli session by its identifier.
append_system_promptNoAppend extra instructions to the default system prompt.

Output Schema

ParametersJSON Schema
NameRequiredDescription
contentYesThe assistant's final answer.
is_errorYes
exit_codeNo
num_turnsNo
timed_outYes
truncatedYes
session_idNoqodercli session id for follow-ups.
duration_msNo
total_creditsNo

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
modelsYesModel names as an array.
contentYesModel names, one per line.

TDQS

A4.2/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
contentYes

TDQS

A4.5/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

  1. 3 tool updatesv0.4.2
    • First observedask-qoder
    • First observedlist-models
    • First observedlist-sessions

TDQS

A4.4/5.0

Scored across 3 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

Three tools is appropriate for a CLI wrapper MCP server, covering the core interactions (task execution, session management, model listing) without unnecessary bloat.

Completeness5/5

The tool set covers the essential workflows for qodercli: initiating tasks, resuming sessions, and selecting models. No obvious gaps for its intended purpose.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers