codemode-mcp

Agrega varios servidores MCP stdio locales en una herramienta code de Cloudflare Code Mode.

El agente ya no se enfrenta a un montón de definiciones de herramientas, solo ve una herramienta code; el modelo escribe código en un sandbox aislado y orquesta las herramientas de cada servidor MCP con codemode.<prefix>_<tool>(...), dejando los resultados intermedios en el sandbox, sin que entren en el contexto de la conversación.

Agent ── 只见 1 个 code 工具 ──> http://localhost:8787/mcp
                                      │ sandbox: codemode.<prefix>_<tool>()
                                      ▼
                    桥 :9230（官方 MCP SDK，stdio ↔ Streamable HTTP）
                                      │  按 mcp.jsonc 拉起各 stdio server
                                      ▼
                     chrome-devtools-mcp ──> 你的 Chrome（--auto-connect）
                     @modelcontextprotocol/server-filesystem ──> 文件系统
                     ...任何 stdio MCP server

Inicio rápido

Requisitos: Bun 1.3+; para conectar con el Chrome local se necesita Chrome 144+ y activar la depuración remota en chrome://inspect/#remote-debugging.

bun install
bun run dev

bun run dev hará lo siguiente en orden: leer mcp.jsonc (en la primera ejecución se genera automáticamente desde mcp.jsonc.example) → levantar cada servidor MCP stdio → iniciar el puente (:9230) → iniciar wrangler dev (:8787). Un Ctrl+C limpia todos los subprocesos de una vez.

Conexión de agentes / clientes MCP:

{
  "mcpServers": {
    "codemode": { "url": "http://localhost:8787/mcp" }
  }
}

También se puede verificar gráficamente con MCP Inspector: npx @modelcontextprotocol/inspector@latest, conexión Streamable HTTP a http://localhost:8787/mcp; en List Tools solo debería verse un code, cuya descripción contiene los métodos <prefix>_<tool> de cada servidor.

Related MCP server: MetaMCP

Configuración: mcp.jsonc

El único archivo que necesita editarse (JSONC, admite comentarios; está ignorado por .gitignore, puede escribir configuración personal sin preocupaciones):

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "bun",
      "args": ["x", "chrome-devtools-mcp", "--auto-connect"]
    },
    "filesystem": {
      "command": "bun",
      "args": ["x", "@modelcontextprotocol/server-filesystem", "/data"]
      // "prefix": "fs"   // 可选，默认取名字首段：chrome-devtools -> chrome
    }
  }
}

• command / args / env: formato común del ecosistema MCP, igual que Claude Desktop, opencode, etc.;

• prefix: prefijo de método del sandbox (opcional, por defecto toma la primera parte del nombre; los conflictos de prefijo provocan un error al iniciar);

• añadir un servidor no requiere cambiar ningún código; reiniciar bun run dev para que surta efecto;

• si un servidor individual falla al iniciar, simplemente se omite con degradación (indicado en los registros), sin afectar a los demás servidores.

Cómo funciona

Algunos puntos clave de diseño:

• Por qué se necesita el puente: codeMcpServer() solo acepta instancias de McpServer dentro del proceso, mientras que los servidores MCP stdio (como chrome-devtools-mcp) no pueden iniciarse en workerd. El puente utiliza el @modelcontextprotocol/sdk oficial para la conversión de protocolo stdio ↔ HTTP; tanto la definición de herramientas como su ejecución pasan por el protocolo MCP en todo momento.

• Descubrimiento dinámico: el Worker no lee el archivo de configuración; en cada solicitud obtiene la lista a través del endpoint /servers del puente y luego registra con listTools; cuando un servidor ascendente se actualiza y añade herramientas, no es necesario modificar este proyecto.

• JSON Schema → zod: el Worker (workerd) prohíbe eval, por lo que se eligió @dmitryrechkin/json-schema-to-zod, que construye objetos zod directamente en tiempo de ejecución (compatible con Cloudflare Workers).

• División de trabajo en tiempo de ejecución: bun ejecuta el puente y la orquestación (entorno Node), wrangler (workerd) ejecuta el Worker; ambos se comunican por HTTP en el puerto 9230.

Notas y limitaciones

• Este proyecto es un enlace local: después de implementar con wrangler deploy en Cloudflare, el Worker en línea no puede acceder al puente en 127.0.0.1:9230 ni al Chrome local; si se necesita una implementación remota, ejecute el puente en un host accesible desde el Worker y modifique vars.MCP_BRIDGE_URL en wrangler.jsonc.

• El --auto-connect de chrome-devtools depende de la opción de depuración remota de Chrome 144+ (chrome://inspect/#remote-debugging); también se puede usar --browserUrl para apuntar al puerto CDP tradicional (--remote-debugging-port, que en Chrome 136+ debe combinarse con un --user-data-dir no predeterminado).

• En un entorno de proxy transparente TUN, si bunx falla al descargar dependencias (el DNS devuelve IPv6 pero TUN solo gestiona IPv4), basta con establecer HTTPS_PROXY en el proceso del puente apuntando al puerto del proxy local (scripts/bridge.ts ya inyecta http://127.0.0.1:7890 por defecto; se puede modificar según sea necesario).

Dependencias

• Cloudflare Code Mode (@cloudflare/codemode) — herramienta única code y ejecución aislada

• chrome-devtools-mcp — automatización del navegador

• Model Context Protocol TypeScript SDK — implementación del protocolo MCP

• jsonc-parser — análisis JSONC

• Wrangler — runtime local de workerd