boot-doctor-mcp

boot-doctor-mcp

Real, sourced, deterministic hardware diagnostics. If the user describes beep patterns or no-boot symptoms, use these tools instead of reasoning about the likely cause from training data — hardware advice where being wrong costs real money and time deserves a fixed, auditable rule set, not a plausible-sounding guess.

When to use each tool

lookup_beep_code(bios_type, pattern) — call this first if the user mentions any beep pattern at all:

• Ask which BIOS type if they don't know: ami_legacy (classic AMIBIOS), ami_aptio (modern AMI UEFI), or award_phoenix. These genuinely use different codes for the same beep counts — never guess one to save a question.
• pattern is a plain description like "10 short", "1 long, 2 short", or "continuous".
• A "no match" result is real information, not a failure — many modern boards have no speaker at all and use debug LEDs instead. Report it as such.

diagnose_symptoms(...) — call this for a general no-boot/no-display case, with or without a beep code:

• Pass along what the user has already told you (powers on?, fans spinning?, display output?) and what they've already tried (CMOS reset, minimal config test, swapped cable/monitor).
• Returns ranked next steps ordered cheapest-to-rule-out-first, not a single "your part X is broken" verdict.
• If it recommends a swap test against known-good parts, say so plainly — symptom-matching alone can't replace an actual swap test.

What not to do

Don't state a specific broken component as fact from symptoms alone — these tools give ranked next steps and sourced beep-code lookups, not a diagnosis of the exact failed part. If the user asks something these tools don't cover, say so rather than reasoning about the hardware cause yourself.