zaungast¶

可以，而且这反而更适合你的约束。

关键点是：zaungast 现在不需要你在 target machine 上装 Rust。它的公开安装方式是通过 Node.js/npm 运行，要求是 New Teams + Node.js ≥ 22.5；常见方式就是 npx -y zaungast，它会自动发现本地 Teams 数据库。(GitHub)

Gemini CLI 本身也支持直接注册 stdio MCP server，命令形式是：

gemini mcp add <name> <command> [args...]

所以最直接的版本就是：

gemini mcp add zaungast npx -y zaungast

默认写到当前项目的 .gemini/settings.json；如果你想用户级全局可用，可以加：

gemini mcp add --scope user zaungast npx -y zaungast

Gemini CLI 官方文档确认 gemini mcp add 支持 stdio server，并且会把 command/args 写进 mcpServers 配置。(GitHub)

不过你这里真正的限制不是 Rust/Python，而是“外部 npm registry 能不能访问”。

npx -y zaungast 的工作方式本质上是：

Gemini CLI
   ↓
launch npx
   ↓
npm registry 下载 zaungast
   ↓
启动 MCP stdio server
   ↓
读取本机 Teams cache

所以如果 target machine 不能访问公共 npm registry，那么单纯：

npx -y zaungast

仍然会失败。

你的环境下，我建议优先考虑这三种部署方式，按优先级排序：

如果内部 npm registry 已经 mirror 了 zaungast，直接让 npm 指向内部 registry，然后照常 npx。
如果内部源没有 zaungast，在允许联网的机器上把 Node package 打包成 tarball，然后通过内部 artifact repository/软件分发渠道下发。
最稳的是预先把 zaungast 和它的 npm dependencies vendoring/打包成一个目录或内部 npm package，然后 Gemini 直接启动本地 executable，不运行在线安装。

对于受限生产机，我最推荐第 3 种。最终 target machine 上的配置应该更像：

{
  "mcpServers": {
    "zaungast": {
      "command": "node",
      "args": [
        "C:\\tools\\zaungast\\dist\\index.js"
      ]
    }
  }
}

或者如果包本身提供 bin entrypoint：

{
  "mcpServers": {
    "zaungast": {
      "command": "C:\\tools\\zaungast\\zaungast.cmd"
    }
  }
}

而不是每次 Gemini 启动都：

npx -y zaungast

原因很简单：npx -y 是 deployment-time dependency resolution，不够 deterministic。你的 target machine 是受控环境，最好把 dependency resolution 放在 build/staging machine 完成，target 只执行已经审批过的 artifact。

架构上因此可以进一步大幅简化。你之前那套 Python ingestion layer 甚至可能第一版完全不要：

                       Target machine

New Teams local cache
        ↓
     zaungast
        ↓ MCP
    Gemini CLI
        ↓
 teams-digest skill
        ↓
structured digest

你的 skill 不需要自己：

parse LevelDB
normalize IndexedDB
install dfindexeddb
maintain Python parser

而是告诉 Gemini：

1. 调用 zaungast 搜索近期 Teams 内容
2. 按 topic/thread 获取相关 conversation
3. 不要 bulk dump
4. 基于 message evidence 提取
   - decisions
   - actions
   - blockers
   - open questions
5. 输出 digest

这实际上更符合 MCP 的设计：让 zaungast 负责 deterministic data access，让 Gemini skill 负责 reasoning/orchestration。

还有一个细节值得注意。Gemini CLI 会给 MCP tools 加 server alias 前缀，因此如果 server alias 是 zaungast，模型看到的工具会类似：

mcp_zaungast_<tool-name>

Google 还特别建议 MCP server alias 不要带 underscore，因为它的 policy engine 会基于第一个 underscore 解析 server 名。zaungast 这个名字本身没有问题。(GitHub)

所以你新的 deployment strategy 我建议直接改成：

Build/staging machine
    |
    +-- obtain/audit zaungast
    +-- npm install/package
    +-- pin exact version
    +-- package dependencies
    +-- publish approved artifact internally
                  |
                  v
Target machine
    |
    +-- Node.js >= 22.5
    +-- Gemini CLI
    +-- approved local zaungast artifact
    |
    v
gemini mcp add zaungast <local command>
    |
    v
teams-digest agent skill

这样 target machine 完全不需要 Rust，也几乎不需要额外 Python package。

甚至如果你的 digest 本身完全交给 Gemini CLI，Python 可以归零：

Python packages: 0
Rust toolchain:   0
Required:
- Gemini CLI
- Node.js >= 22.5
- zaungast artifact

唯一我仍然会考虑加 Python 的情况，是你需要长期的：

incremental state
cross-day digest snapshots
SQLite evidence database
action-item lifecycle
decision supersession tracking

那时 Python 是“digest state layer”，而不是 Teams extraction layer。这样 Python 包也可以压到几乎只有 stdlib + pydantic，甚至纯 stdlib。

基于你现在这个新约束，我会修改之前的方案：第一版不要自己解析 Teams，不要装 dfindexeddb，不要依赖任何附件解析 Python 包。先验证 Gemini CLI ↔ zaungast MCP ↔ local Teams 这条链能否工作。

验证只需要：

node --version
gemini --version

然后安装/放置 zaungast，注册：

gemini mcp add --scope user zaungast <approved-local-zaungast-command>

最后：

gemini mcp list

Gemini CLI 会显示 MCP connection 状态；stdio server 在受信任目录下才会被正常测试连接。(GitHub)

如果这条链通了，你的整个 teams-digest 项目就从“写一个 Teams data pipeline”变成“写一个很薄的 Gemini Agent Skill”。这会简单一个数量级。