# boot-doctor-mcp

<!-- mcp-name: io.github.pamela-0/boot-doctor-mcp -->

[![PyPI](https://img.shields.io/pypi/v/boot-doctor-mcp)](https://pypi.org/project/boot-doctor-mcp/) [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)

A real MCP server for PC no-boot / no-display / no-POST troubleshooting. **No LLM guessing at hardware causes** — a plain, deterministic rule engine plus real, sourced BIOS beep-code tables.

## Why deterministic, not an LLM

Nobody wants a language model hallucinating "your GPU is dead" when it isn't. Hardware advice where being wrong costs real money and real time deserves a fixed, auditable rule set, not a plausible-sounding guess. Every answer this tool gives traces back to a real source or a fixed, testable rule — never an invented explanation.

## Tools

### `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)`

Real, ranked next troubleshooting steps, given what's already been tried — the same power-stage → CMOS reset → minimal-config-test → swap-test sequence a real technician runs, ordered by what's cheapest to rule out first. Not a diagnosis of the exact broken part; a real repair often still needs a swap test against known-good parts, and this tool says so explicitly rather than pretending symptom-matching alone can replace it.

### `lookup_beep_code(bios_type, pattern)`

Looks up a beep pattern (e.g. `"10 short"`, `"1 long, 2 short"`, `"continuous"`) against real, sourced BIOS beep-code tables.

`bios_type` is one of:
- `ami_legacy` — classic AMIBIOS
- `ami_aptio` — modern AMI Aptio (UEFI), kept **separate on purpose**: legacy AMIBIOS and Aptio use genuinely different codes for the same beep counts, a mistake common in beginner troubleshooting guides that merge them into one table
- `award_phoenix` — Award/Phoenix BIOS

Returns real information, not a fabricated guess, when the exact pattern isn't in the table — modern boards increasingly have no speaker at all and use debug LEDs instead, so "no match" is itself a real, honest result.

## Sources

Beep-code data fetched and cross-referenced live (not from training-data memory) from [IONOS](https://www.ionos.com/digitalguide/server/know-how/bios-beep-codes/) and [Thomas-Krenn](https://www.thomas-krenn.com/en/wiki/AMI_BIOS_Beep_Codes_Overview). Real, stated limitation: OEMs (HP, Dell, ASUS, etc.) sometimes customize or extend these codes, and modern boards increasingly skip the speaker entirely in favor of debug LEDs — a documented pattern not matching here doesn't necessarily mean nothing is wrong.

## Install

```bash
pip install boot-doctor-mcp
```

Add to your MCP client config (e.g. Claude Code):

```bash
claude mcp add boot-doctor-mcp -- boot-doctor-mcp
```

Or run directly for local testing:

```bash
python -m boot_doctor_mcp.server
```

## Skill

A `SKILL.md` ships inside this same package — not a separate download — and teaches Claude when and how to use these tools correctly (e.g. never guessing a BIOS type, never stating a broken component as fact from symptoms alone). Install it into your project:

```bash
boot-doctor-mcp-install-skill
```

Run it from the project root you want the skill active in — it writes to `.claude/skills/boot-doctor-mcp/SKILL.md` relative to your current directory.

## Development

```bash
pip install -e ".[dev]"
pytest
```