[Bug] Local MCP plugins not starting — restart_mcp_with_logs returns 0/0, engine scan phase skips all plugins

[BeadyTooth57254]

提交前确认 / Before submitting

• 我已经搜索过现有 Issue，确认这不是重复问题。
• 我已经移除日志、截图和配置中的密钥及隐私信息。

Operit 版本 / Operit version

1.12.1

运行形态 / Distribution

Release APK

设备与运行环境 / Environment

Android 12，SDK 31。OPPO PFGM00

问题领域 / Area

Plugin, Skill or MCP / 插件、Skill 或 MCP

主要问题描述 / Main problem description

All MCP plugins — both local (stdio/npx) and remote (httpStream) — stopped working.
restart_mcp_with_logs consistently returns "0 success, 0 failed" in 250ms,
indicating the MCP engine scan phase finds no plugins. Manual restart via UI
also has no effect. Local MCP deployment directories in Linux (/mcp_plugins/)
are incomplete (hotnews is empty, office-word has files but no venv).
However, manual pnpm dlx @wopal/mcp-server-hotnews in the Linux terminal
works fine — proving dependencies/networking are OK, it's the Operit MCP
engine that isn't launching anything.

This may share a root cause with #907 (remote MCP tools not registering),
but our case additionally includes local plugins failing at the scan/launch
stage, not just at tool registration.

复现步骤 / Steps to reproduce

1. Have local and remote MCP plugins configured in mcp_config.json
   (e.g. hotnews: npx command-type, office-word: Python local,
   galatea_garden/numen/ombre_brain: httpStream remote)
2. Open Operit → MCP management page → tap restart
   OR call restart_mcp_with_logs via API
3. Observe: response returns 0 success / 0 failed in ~250ms
4. Check AI tool panel: no MCP tools available
5. Check logcat: no MCP-related entries (McpPlugin, deploy_mcp,
   startPlugin, initMCP — all absent)

复现频率 / Reproducibility

Always / 每次发生

相关配置 / Related context

• Device: OPPO PFGM00, Android 12 (SDK 31), Shizuku enabled (not rooted)
• App version: latest as of 2026-08-12
• Previous working state:
  • hotnews: last started 2026-07-22, stopped 86s later
  • galatea_garden: last stopped 2026-08-09 00:25
  • ombre_brain: last stopped 2026-08-10
  • Issue first noticed: 2026-08-12
• Sandbox packages (81 installed) work normally — only MCP is broken
• mcp_config.json is valid and complete (see Logs section)
• Linux deploy directory ~/mcp_plugins/hotnews/ is empty
• Manual pnpm dlx test: succeeds (see Logs section)
• restart_mcp_with_logs: always returns {successCount:0, failedCount:0, plugins:[]}
• UI manual restart: no effect

截图或录屏 / Screenshot or recording

日志或错误信息 / Logs or error output

【1. restart_mcp_with_logs 返回结果】
{successCount: 0, failedCount: 0, plugins: []}
耗时: ~251ms

【2. 手动 pnpm dlx 测试 — 成功】
$ cd ~/mcp_plugins/hotnews && timeout 15 pnpm dlx @wopal/mcp-server-hotnews
Hot news MCP server running on stdio
→ 证明依赖和网络正常

【3. Linux 部署目录状态】
~/mcp_plugins/
├── hotnews/ ← 空目录，无文件
├── mcp-github-com-gongrzhe-office-word-mcp-server/ ← 有源码，缺 venv
└── mcp-github-com-regenrek-deepwiki-mcp/ ← 有文件

【4. mcp_config.json — mcpServers 部分】
"hotnews": {
"command": "npx",
"args": ["-y", "@wopal/mcp-server-hotnews"],
"disabled": false
}
"office-word": {
"command": "~/mcp_plugins/.../venv/bin/python",
"args": ["-m", "word_document_server.main"],
"disabled": false
}
→ 配置格式正确，disabled 均为 false

【5. mcp_config.json — pluginMetadata 远程插件（4个，均为 httpStream）】
galatea_garden: disabled=false, endpoint=https://galatea.abysslumina.com/mcp
ombre_brain: disabled=false, endpoint=https://es-sentinel.zeabur.app/mcp
for_the_sentinel: disabled=false, endpoint=https://for-the-sentinel.zeabur.app/mcp
numen: disabled=false, endpoint=http://192.168.100.236:8765/mcp
→ 均未禁用

【6. server_status.json 最后活动时间】
hotnews: lastStart=2026-07-22, lastStop=2026-07-22 (运行86秒)
galatea_garden: lastStart=2026-08-05, lastStop=2026-08-09
for_the_sentinel: lastStart=2026-08-04, lastStop=2026-08-06
ombre_brain: lastStart=2026-08-09, lastStop=2026-08-10
numen: lastStart=0, lastStop=0 (从未启动)
→ MCP 引擎停摆时间与各插件最后活动时间吻合

【7. logcat — MCP 相关条目】
搜索关键词: McpPlugin, deploy_mcp, startPlugin, initMCP, MCP
结果: 0 条匹配（2026-08-12 11:00 重启后的所有日志中均无 MCP 相关输出）
→ MCP 引擎完全静默

【8. 对比：Sandbox 包正常】
2026-08-12 11:00 重启日志中 Sandbox 包扫描正常: "loaded 109 packages, 0 errors"

[BeadyTooth57254]

和#907
类似，但是我这本地的MCP也无法运行，skills等正常使用

[BeadyTooth57254]

补充发现：远程 MCP 在管理页面停留后会亮绿灯，但工具仍不可用

在 MCP 管理页面停留十几秒后，三个远程 httpStream 插件（galatea_garden、ombre_brain、for_the_sentinel）的状态指示灯会变绿，说明管理页面本身有独立的健康检查/重连逻辑，绕过了 restart_mcp_with_logs 直接做 HTTP 握手。但此时 AI 工具面板里仍看不到这些插件的工具。

这进一步印证了 #907 的判断：握手成功 → 工具缓存 → 注册到 AI 工具列表这个流程中，最后一步断了。而本地 MCP 插件（hotnews、office-word）完全不会亮——它们依赖引擎的「扫描→部署→启动进程」链路，这条链路和 restart_mcp_with_logs 共享同一个引擎入口，目前是彻底哑火的。

总结： 管理页面的健康检查（远程握手）和 MCP 引擎的扫描/启动/工具注册是两条不同的路径。前者正常，后者全挂了。

[zql081710]

我今天也这样

【Bug反馈】远程MCP插件启动时显示"MCP runtime connection failed"，但实际未发起连接请求

环境信息

• Operit版本：1.12.1
• Android系统
• 复现时间：2026-08-12 16:19

问题描述
远程MCP插件（connectionType为"http"，type为"remote"）在Operit启动时全部显示"验证失败（MCP runtime connection failed）"，但本地MCP插件（connectionType为"httpStream"）能正常加载。

受影响的插件

1. Galatea Garden（id: galatea-garden，endpoint: https://galatea.abysslumina.com/mcp）
2. CEDAR TOY（id: toy_cedarstar_org，endpoint: https://toy.cedarstar.org/...）

排查过程

1. 配置文件完整性：检查了/sdcard/Download/Operit/mcp_plugins/mcp_config.json，所有必需字段（logoUrl、longDescription、repoUrl、updatedAt等）均已补全，与正常工作的其他remote插件结构一致。

2. 网络与服务端验证：使用extended_http_tools直接向两个endpoint发送标准MCP请求（JSON-RPC 2.0格式，method为"tools/list"，附带Authorization头部），均返回200状态码和完整工具列表，token认证通过，证明网络、服务器、token三方面都没有问题。

3. 启动日志分析：导出Operit启动日志（operit_log_20260812_164427.txt），发现：

• 第30行显示："配置加载完成 - MCP服务器: 1, 插件元数据: 4"——Operit能正常读取配置文件并识别出4个插件
  • 但整个日志中完全没有对Garden或CEDAR TOY的endpoint发起连接请求（搜索"https://galatea"、"https://toy"均无结果）
  • 日志中仅显示对本地MCP的连接尝试（127.0.0.1:32145）

根本原因
Operit启动时的远程MCP加载逻辑未被触发或被跳过。客户端能正确解析配置文件并识别出远程MCP插件，但没有执行实际的HTTP连接操作。这不是"连接失败"，而是"压根没去连"。

日志证据

2026-08-12 16:19:12.500 D/MCPLocalServer: 配置加载完成 - MCP服务器: 1, 插件元数据: 4

此后日志中没有任何针对远程endpoint的HTTP请求记录。

错误模式

• 远程MCP（http类型）：全部失败
• 本地MCP（httpStream类型）：全部成功

预期行为
Operit启动时应该对配置文件中所有远程MCP插件的endpoint发起初始化连接（如tools/list请求），验证连接有效性后再标记为"已加载"或"验证失败"。

建议排查方向
MCPLocalServer或相关的远程MCP启动模块可能存在：

1. 条件判断错误导致远程MCP启动代码未执行
2. 异步任务未正确调度
3. 某个前置检查失败导致静默跳过远程MCP加载流程

[BeadyTooth57254]

你这个看看#907吧，感觉那个bug和你的更匹配一些？