结论

Claude Desktop 的 managed MCP，不是 mcpServers object，而是 managedMcpServers array-of-entries。把字段名和结构同时写错，是这次最开始的根因。

背景

想让 Claude Desktop 连上 Hindsight 服务。服务端正常：http://localhost:8888/mcp/hermes/ 可访问，后端可用，bridge 可用。

一开始写的是：

"mcpServers": {
  "hindsight": {
    "command": "npx",
    "args": [
      "-y",
      "mcp-remote",
      "http://127.0.0.1:8888/mcp/hermes/",
      "--transport",
      "http-only"
    ]
  }
}

结果呢？服务没连上。

核心判断

managed config 认的键是 managedMcpServers。 值不是 object，而是 array-of-entries。 每一项是独立 entry，不是 keyed map。

正确写法：

"managedMcpServers": [
  {
    "name": "hindsight",
    "transport": "stdio",
    "command": "npx",
    "args": [
      "-y",
      "mcp-remote",
      "http://127.0.0.1:8888/mcp/hermes/",
      "--transport",
      "http-only"
    ]
  }
]

桥梁本质没有变：还是 npx mcp-remote ... --transport http-only。 没说 bridge 不行，其实是 config key 不存在。

依据

  • 从 Desktop 应用资源和初始化日志里，实际解析的是 managedMcpServers。

  • 同一 config 里先前出现过：

    Failed to parse managed config "managedMcpServers": .: invalid_type

  • 改成正确字段和结构后，日志变为：

    [custom3p-mcp] connected { name: 'hindsight', toolCount: 29, ... }

常见误区

  • 把非 managed 写法误当成 3P managed 写法。
  • 以为 HTTP transport 可以直接在 Desktop app 里原生支持。
  • 修改了非生效文件，没改到 Desktop 真正读取的 config。

方法论

先找 Desktop 实际读哪份 config。 再用最小字段改动验证，不要一上来重建整个配置。 拿到日志证据再下结论，不要凭 UI 列表判断成败。

结语

根因不是 Hindsight 服务问题，不是 bridge 问题，而是 managed config schema 用错了。下一章谈：entry 连上之后，为什么一度看起来只有 1 个工具可用。