先别把 ltc6539/mcp-ppt 当成“丢进去就自动出完稿”的万能按钮。按仓库说明看，它更像一段 MCP 接入流程：先弄清输入材料，再把依赖、配置和最小输出跑通，最后才接真实 PPT 材料。

新手最容易跳过的是安装后的第一轮验证。PPT maker MCP server 的线索集中在 pyproject.toml 和仓库目录里，能不能用，先看 客户端能不能发现工具并返回结果，不是看 README 里写了多少能力。This MCP server enables dynamic creation, editing and saving of PowerPoint presentations.

先看 ltc6539/mcp-ppt 要接住哪一种材料

安装前先把边界定住：这份教程按 MCP 接入流程 来用，不把它写成普通项目浏览。仓库里能看到 README.md、pyproject.toml，这些文件决定了后面该查 README、SKILL.md、脚本入口还是包管理配置。

如果手里的材料和仓库目标不一致，后面命令跑通也没有意义。比如一个偏 MCP 的仓库要先看客户端识别，一个偏 PPTX 的仓库要看最终文件，一个偏论文汇报的仓库要看结构拆分是否稳定。

ltc6539/mcp-ppt 安装先对齐 pyproject.toml、依赖和 Codex 识别

1. 克隆仓库：git clone https://github.com/ltc6539/mcp-ppt.git mcp-ppt。
2. 进入目录：cd mcp-ppt。
3. 先读 README 和 SKILL.md，确认入口文件、输入材料、输出目录和限制；这一步不要跳过。
4. 安装依赖：python -m pip install -e .。如果仓库 README 写了 pnpm、bun、yarn、uv 或 Docker，就按 README 替换这里的命令。
5. 检查 API Key、环境变量和模型权限；仓库没写专门密钥时，也要确认 Codex 或本地模型环境能正常调用。
6. 重启或刷新 Codex 后，用 先在本地客户端里做最小调用，不要直接上完整项目。

安装成功的标志要具体：目录里能看到 pyproject.toml，依赖安装没有缺包提示，Codex 能识别这个 skill 或脚本命令能启动。只看到 git clone 成功，还不能算完成。

第一次小测试只验证 客户端能不能发现工具并返回结果

1. 准备一个最小输入，材料越短越好，先避免长论文、大批图片或完整客户稿。
2. 按 README 或脚本帮助信息运行最小命令；如果没有明确命令，就先让 Codex 调用该 skill 处理一个短任务。
3. 观察 PPTX 文件 是否出现，同时保留终端日志或 Codex 返回结果。
4. 把失败信息分成三类：依赖缺失、路径写错、模型或 API Key 不可用；不要把三类问题混在一起反复试。

这一步的成功标志不是“看起来在运行”，而是 PPTX 文件 可打开、可检查，并且日志里没有缺依赖、缺密钥或路径不可写的错误。

看到 PPTX 文件 后先做 ltc6539/mcp-ppt 的结果体检

mcp-ppt 跑通后，先检查输出目录、生成文件和日志。PPT 类 skill 尤其要看最终文件能否打开，页面或对象是否还能编辑，中间 JSON、assets、report 这类文件是否完整。

如果输出只有一段文字说明，没有 PPTX 文件、没有报告、没有可复查的中间目录，就先退回小测试。E194 的标准是让读者照着做能定位结果，而不是只看一段顺滑的说明。

ltc6539/mcp-ppt 还没过小样本时别进生产材料

真实材料里常见的坑是权限和隐私：公司内部 PPT、未公开论文、客户方案、带品牌素材的截图，都要先确认模型调用位置、缓存目录和输出文件落点。API Key 或环境变量一旦配错，失败信息可能不会直接写在标题里。

最后按四项收尾：ltc6539/mcp-ppt 是否放在正确目录，依赖是否装在正在运行的环境里，第一次小测试是否产生 PPTX 文件，失败时能否从日志或报告定位原因。四项都成立，再接真实材料；少一项，就先停在本地小样本。