boot-doctor-mcp

一个用于 PC 无法启动 / 无显示 / 无法通过 POST 故障排查的真正 MCP 服务器。不靠 LLM 猜测硬件原因——一个简单、确定性的规则引擎，外加真实、有来源的 BIOS 蜂鸣代码表。

为什么是确定性的，而不是 LLM

没有人希望语言模型在 GPU 并没有坏的时候产生“你的 GPU 坏了”这样的幻觉。硬件建议一旦出错就要付出真金白银和实实在在的时间，因此它值得一套固定、可审计的规则集，而不是一个听起来貌似合理的猜测。这个工具给出的每一个答案都能追溯到真实来源或固定、可测试的规则——绝不会是凭空编造的解释。

Related MCP server: System Information MCP Server

工具

diagnose_symptoms(powers_on, fans_spin=None, fans_stay_running=None, display_output=False, tried_cmos_reset=False, tried_minimal_config=False, tried_different_cable_or_monitor=False)

根据已经尝试过的操作，给出真实、按优先级排序的下一步排查步骤——与真正的技术人员执行的流程相同：电源阶段 → CMOS 重置 → 最小配置测试 → 替换测试，按照成本最低者优先排除的顺序排列。这不是对具体损坏部件的诊断；真正的维修往往仍然需要用已知良好的部件进行替换测试，而这个工具会明确说明这一点，而不是假装仅凭症状匹配就能替代它。

lookup_beep_code(bios_type, pattern)

在真实、有来源的 BIOS 蜂鸣代码表中查找蜂鸣模式（例如 "10 short"、"1 long, 2 short"、"continuous"）。

bios_type 是以下之一：

• ami_legacy — 经典 AMIBIOS

• ami_aptio — 现代 AMI Aptio（UEFI），有意分开：传统 AMIBIOS 和 Aptio 对相同的蜂鸣次数使用完全不同的代码，而初学者故障排查指南中常见的错误就是把它们合并到一张表里

• award_phoenix — Award/Phoenix BIOS

当表中没有完全匹配的模式时，返回的是真实信息，而不是编造的猜测——现代主板越来越普遍地根本不带蜂鸣器，而是改用调试 LED，因此“无匹配”本身就是一个真实、诚实的结果。

来源

蜂鸣代码数据实时获取并交叉核对自 IONOS 和 Thomas-Krenn（而非来自训练数据的记忆）。一个真实且已明确说明的局限：OEM（HP、Dell、ASUS 等）有时会定制或扩展这些代码，而且现代主板越来越倾向于完全省去蜂鸣器、改用调试 LED——因此，某个有记录的蜂鸣模式在这里找不到匹配，并不一定意味着没有问题。

安装

pip install boot-doctor-mcp

将其添加到你的 MCP 客户端配置中（例如 Claude Code）：

claude mcp add boot-doctor-mcp -- boot-doctor-mcp

或者直接运行以进行本地测试：

python -m boot_doctor_mcp.server

开发

pip install -e ".[dev]"
pytest