canbus-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@canbus-mcpcapture CAN bus frames for 10 seconds"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
canbus-mcp
A CAN bus reverse engineering MCP server for Claude Code. Lets Claude read, analyze, and map CAN bus messages from automotive and motorsport ECUs directly from the conversation.
Built around the PEAK PCAN-USB adapter. Designed for reverse engineering unknown CAN buses without DBC files — though DBC import/export is supported.
Hardware
PEAK PCAN-USB (IPEH-002021)
Related MCP server: cc-session-search
Requirements
Python 3.11+
macOS or Windows
PEAK PCBUSB driver (macOS) or PEAK Windows driver
Installation
1. Install the PEAK driver
macOS:
PEAK does not provide a native macOS driver. Use the open-source PCBUSB library from mac-can.com:
Download the PCBUSB package
Run the installer — if
install.shdoes nothing,/usr/local/liblikely doesn't exist on your machine. Fix it manually:
sudo mkdir -p /usr/local/lib
sudo cp ~/Downloads/PCBUSB*/libPCBUSB.0.13.dylib /usr/local/lib/
sudo ln -sf /usr/local/lib/libPCBUSB.0.13.dylib /usr/local/lib/libPCBUSB.0.dylib
sudo ln -sf /usr/local/lib/libPCBUSB.0.dylib /usr/local/lib/libPCBUSB.dylibWindows:
Download and install the PEAK driver from peak-system.com. No additional steps needed.
2. Install canbus-mcp
git clone https://github.com/YOUR_USERNAME/canbus-mcp
cd canbus-mcp
python3 -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -e .3. Add to Claude Code
claude mcp add canbus-re -s user \
-e DYLD_LIBRARY_PATH=/usr/local/lib \
-- /absolute/path/to/canbus-mcp/.venv/bin/python -m canbus_mcp.serverReplace /absolute/path/to/canbus-mcp with the actual path where you cloned the repo.
Windows: Use the full path to .venv\Scripts\python.exe and omit the DYLD_LIBRARY_PATH env var.
Restart Claude Code and run /mcp to confirm canbus-re appears as connected.
Usage
Start a Claude Code session and describe what you want to reverse engineer. The recommended workflow:
detect_baudrate_auto() # auto-sniff bus speed from live traffic
connect() # open the interface
capture(duration=10) # record frames
get_traffic_summary() # see all message IDs, frequencies, DLCs
take_snapshot('idle') # baseline snapshot
# trigger a physical event (press throttle, turn wheel, etc.)
capture(duration=5)
take_snapshot('event')
compare_snapshots('idle', 'event') # find what changed
analyze_message(0x1A0) # byte-level breakdown of a specific ID
track_signal(0x1A0, 2, 2) # watch bytes [2:4] change over time
define_signal('engine_rpm', 0x1A0, 16, 16, scale=0.25, unit='rpm')
export_dbc('/path/output.dbc')OBD2
For standard OBD2 vehicles (500k or 250k baud, 11-bit IDs):
check_obd2_support() # check which PIDs are available
read_obd2_pids() # query RPM, speed, throttle, temps, etc.Tools
Tool | Description |
| Show available hardware and current connection |
| Auto-detect baud by listening for valid frames |
| Open CAN interface |
| Close interface |
| Record frames for N seconds |
| Save capture buffer as named snapshot |
| Diff two snapshots to find changed bytes |
| All IDs: frequency, DLC, count |
| Per-byte entropy, counter/checksum detection |
| Extract a byte range's values over time |
| Name a discovered signal (bit position, scale, offset) |
| Decode raw hex against known signals |
| Load a DBC file |
| Export defined signals as DBC |
| Check OBD2 PID support |
| Query all standard OBD2 PIDs |
| Send a raw OBD2 request |
Available Tools
21 toolsanalyze_messageA
Deep-analyze a single CAN message ID across all captured frames. Reports per-byte entropy, counter/checksum detection, and signal candidates.
Args: can_id: CAN message ID in decimal (e.g. 1234) or use int('0x4B0', 16).
| Name | Required | Description | Default |
|---|---|---|---|
| can_id | Yes |
captureA
Capture CAN frames for a fixed duration. Frames accumulate in the internal buffer for use by analysis tools.
Args: duration: Capture window in seconds. filter_ids: Optional list of decimal CAN IDs to capture. None = capture all.
| Name | Required | Description | Default |
|---|---|---|---|
| duration | No | ||
| filter_ids | No |
check_obd2_supportA
Query OBD2 service 01 PID 00 to check if the vehicle supports OBD2 and which PIDs are available. Requires connection to the vehicle CAN bus (typically 500k or 250k baud on 11-bit ID bus).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
clear_captureA
Clear all captured frames from the internal buffer. Does not affect snapshots.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
compare_snapshotsA
Diff two named snapshots to find which IDs and bytes changed.
Args: before_name: Label of the baseline snapshot. after_name: Label of the post-event snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| before_name | Yes | ||
| after_name | Yes |
connectA
Open a connection to a CAN interface.
Args: interface: Interface type ('pcan' for PEAK PCAN-USB, 'virtual' for testing). channel: Channel name (e.g. 'PCAN_USBBUS1'). baudrate: Bus speed in bps. Common: 500000, 250000, 1000000, 125000.
| Name | Required | Description | Default |
|---|---|---|---|
| interface | No | pcan | |
| channel | No | PCAN_USBBUS1 | |
| baudrate | No |
decode_frameA
Decode a raw CAN frame against all known signal definitions for that CAN ID.
Args: can_id: CAN message ID. data_hex: Frame payload as a hex string, e.g. '0A1B2C3D4E5F6789'.
| Name | Required | Description | Default |
|---|---|---|---|
| can_id | Yes | ||
| data_hex | Yes |
define_signalA
Define a named signal from a CAN message (bit-level precision). Physical value = (raw * scale) + offset.
Args: name: Signal name, e.g. 'engine_rpm' or 'throttle_pct'. can_id: CAN message ID. start_bit: LSB position (little_endian) or MSB position (big_endian), 0-based. length: Signal width in bits. byte_order: 'little_endian' (Intel/LSB-first) or 'big_endian' (Motorola/MSB-first). value_type: 'unsigned' or 'signed'. scale: Multiplier for raw→physical conversion. offset: Addend for raw→physical conversion. unit: Physical unit string, e.g. 'rpm', 'km/h', '%', '°C'. description: Human-readable description.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| can_id | Yes | ||
| start_bit | Yes | ||
| length | Yes | ||
| byte_order | No | little_endian | |
| value_type | No | unsigned | |
| scale | No | ||
| offset | No | ||
| unit | No | ||
| description | No |
detect_baudrate_autoA
Auto-detect CAN bus baudrate by listening for valid frames at each common rate. Tries: 500k, 250k, 1M, 125k, 100k, 83.3k, 50k, 33.3k, 20k, 10k bps.
Requires live traffic on the bus. If the bus is idle, put the vehicle/ECU into a state that generates traffic (ignition on, engine running) before calling this.
Args: interface: CAN interface type. Use 'pcan' for PEAK PCAN-USB. channel: Interface channel. Default 'PCAN_USBBUS1' for first PCAN-USB device. timeout_per_rate: Seconds to listen at each baudrate before trying next.
| Name | Required | Description | Default |
|---|---|---|---|
| interface | No | pcan | |
| channel | No | PCAN_USBBUS1 | |
| timeout_per_rate | No |
disconnectA
Close the current CAN interface connection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
export_dbcA
Export all current signal definitions to a DBC file. Can be opened in SavvyCAN, PEAK PCAN-Explorer, CANdb++, etc.
Args: file_path: Absolute path for the output .dbc file.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
get_traffic_summaryA
Summarize all captured message IDs: frame count, frequency, DLC, and category. High-frequency IDs (>100 Hz) are typically sensor loops. Low-frequency IDs (<5 Hz) are typically status or event-driven messages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
import_dbcA
Import a DBC file and add its signal definitions to the current session. Signals are named as 'MessageName.SignalName'.
Args: file_path: Absolute path to the .dbc file.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
list_interfacesA
List available CAN interface types, channels, and current connection status. Use this first to confirm what hardware/channels are available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
list_signalsA
List all defined signals in the current session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
list_snapshotsA
List all saved snapshots and their frame counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
query_obd2_pidB
Send a raw OBD2 request and return the response bytes.
Args: service: OBD2 service number (e.g. 1 for current data, 3 for DTCs). pid: PID/subfunction number.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | ||
| pid | Yes |
read_obd2_pidsB
Query all known OBD2 PIDs (RPM, speed, throttle, temps, MAF, fuel level, etc.) and return decoded physical values.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
remove_signalB
Remove a signal definition by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
take_snapshotA
Save the current capture buffer as a named snapshot.
Use this for before/after comparison:
Capture baseline traffic → take_snapshot('idle')
Trigger an action (press throttle, turn steering, etc.)
Capture again → take_snapshot('throttle_pressed')
compare_snapshots('idle', 'throttle_pressed') to find changed bytes
Args: name: Snapshot label.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
track_signalA
Extract a byte range from captured frames and show how the value changes over time. Use this to observe a candidate signal while correlating with physical inputs.
Args: can_id: CAN message ID. start_byte: First byte index (0-based). num_bytes: How many consecutive bytes to read (1–4). signed: Interpret as signed integer. scale: Physical = raw * scale + offset. offset: Physical = raw * scale + offset. byte_order: 'little_endian' (Intel) or 'big_endian' (Motorola).
| Name | Required | Description | Default |
|---|---|---|---|
| can_id | Yes | ||
| start_byte | Yes | ||
| num_bytes | No | ||
| signed | No | ||
| scale | No | ||
| offset | No | ||
| byte_order | No | little_endian |
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
21 tool updates
v0.1.0- First observed
analyze_message - First observed
capture - First observed
check_obd2_support - First observed
clear_capture - First observed
compare_snapshots - First observed
connect - First observed
decode_frame - First observed
define_signal - First observed
detect_baudrate_auto - First observed
disconnect - First observed
export_dbc - First observed
get_traffic_summary - First observed
import_dbc - First observed
list_interfaces - First observed
list_signals - First observed
list_snapshots - First observed
query_obd2_pid - First observed
read_obd2_pids - First observed
remove_signal - First observed
take_snapshot - First observed
track_signal
TDQS
Scored across 21 tools
Each tool targets a distinct operation or concept: capture vs. analysis vs. signal definition vs. OBD2. Tools like analyze_message, decode_frame, and track_signal have clearly different purposes (deep analysis, decoding, time-series tracking). No overlapping functionality.
All tool names follow a consistent snake_case verb_noun pattern (e.g., 'analyze_message', 'capture', 'list_signals'). No mixing of styles or vague verbs; names are descriptive and predictable.
21 tools is on the higher end but justified by the complex domain (CAN bus analysis, signal definition, OBD2, snapshots). Each tool covers a necessary function without feeling bloated.
Covers core workflow: capture→signal discovery→definition→export. Includes OBD2 support and snapshot comparison. Minor gaps: no signal editing (only define/remove), no frame sending. But the surface is well-rounded for a monitoring/analysis tool.
Maintenance
Related MCP Connectors
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Shared memory MCP server for Claude Code, Codex, Gemini CLI and Cursor. Cited, editable.
Free WhatsApp MCP server for ChatGPT and Claude: read and search chats, every send you approve.
Meta Ads and Google Ads MCP server: 250+ tools for Claude, ChatGPT, Cursor and Codex.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceMCP server that integrates Ghidra for binary analysis, enabling decompilation, disassembly, and advanced reverse engineering tasks through Claude Code.17MIT
- FlicenseBqualityDmaintenanceAn MCP server that provides tools for searching and analyzing Claude Code conversation history.84-
- AlicenseAqualityDmaintenanceAn MCP server that lets Claude Code recall the context of past conversations from any project on demand.552 npm2MIT
- AlicenseAqualityDmaintenanceAn MCP server that gives Claude AI the ability to read, analyze, modify, and debug ANTLR4 grammars, enabling grammar debugging and manipulation for Claude Desktop.551MIT