Serve the offline analysis to an assistant, read-only, over stdio

[Zenofex]

bootintel mcp speaks MCP over stdio, so an assistant does the reasoning half of reading a boot log while this binary does the reading half.

claude mcp add bootintel -- bootintel mcp

Here is a boot log from a router I am assessing. What should I look at first, and what can you not tell from this capture?

Why local is the point, not a detail

The model is the operator's own, under whatever agreement they already work under, and no capture leaves the machine. A hosted version would have to receive the log, which is the thing an NDA-bound consultancy cannot do and the reason the offline tooling exists at all. It also means this costs nothing to run: the reasoning is paid for by whoever already pays for the assistant.

Read-only, and tested as such

Tool
scan_log	detectors over a capture
boot_chain_verdict	what the boot chain permits, plus the kernel posture
list_detectors	what this build recognises
sample_log	an example, for trying it without a device

None opens a serial port, writes to a device, or reaches the network. the_tool_set_is_read_only asserts the list by name rather than trusting a policy, so adding a write is a deliberate edit somebody reviews. If that ever changes, the allowlist belongs in the process where the bytes are written, not in a prompt: a model can be argued into anything; a refusal in code cannot.

Captures are passed as text rather than a path, so the caller decides what is disclosed instead of the server reading whatever it likes off the disk.

The honesty has to survive a summariser

That is the part most at risk when a model sits between the tool and the reader:

• an empty finding list says the capture was not recognised, not that the device is clean;
• absence is reported as unknown, never as hardened;
• every verdict carries the value it was read from.

Protocol details that break quietly

Notifications get no reply (answering one is an error some clients tolerate and others do not). An unrecognised protocol version falls back rather than failing the handshake. A malformed line does not end the session. A tool failure is a result carrying isError, not a transport error, so the model sees why rather than the client seeing a broken connection.

Verification

• cargo test --workspace --features tui: 402 passed; without: 381 passed
• clippy -D warnings and fmt --check: clean
• A real handshake driven through the built binary: initialize → notifications/initialized → tools/list → tools/call, returning five verdicts and the KASLR reason from a synthetic capture

🤖 Generated with Claude Code