MCP server for AI agents

ECUDeck ships a second small program, ecudeck-mcp, that speaks the Model Context Protocol over stdio. An AI agent such as Claude Desktop, Claude Code or Cursor starts it on your computer and can then look at the same buses, ECUs and traces you have in ECUDeck, with the same connections and the same safety rules. Nothing goes through our servers; we have none.

ECUDeck is in development. The tools marked prototype run today against the built-in simulated vehicle; the rest are planned for the first release. This page describes the design the app is built to.

Reading

By default agents only read: they list connections and adapters, read frames and decoded signals, read DTCs and data identifiers, and search traces. In Edit connection, AI agents can be set to Hidden, Read or Read and send.
ECUDeck Free: one bus per agent session. Pro and Team: every connection.
Frames reach the agent in bounded batches: at most a few hundred frames or a few seconds per call, and payloads are cut to a fixed budget, so a busy bus cannot flood the agent's context.
Every call is written to the ECUDeck log on your computer, and Settings → AI agents shows the running agent sessions.

Sending: you allow each request (Pro and Team)

ecudeck-mcp never touches an adapter. On a connection set to Read and send for agents, a send tool passes the request to the running ECUDeck app on your computer, over a local socket only your user can open.
ECUDeck shows one request at a time: the agent, the connection and its role (lab, bench, vehicle), the adapter and bitrate, every frame exactly as it will go on the wire (identifier, flags, data in hex) or the UDS service and its parameters, and the agent's reason.
Nothing is sent until you click Allow. Vehicle connections also need the connection name typed. Deny, Escape, closing the window or no answer in 60 seconds is a denial, and the agent is told not to retry it unchanged.
Per connection you can set an allow-list of identifiers and payload masks, a rate cap in frames per second, and a dead-man timeout that ends the agent's sending session when the Allow window loses focus or the agent disappears. The first live send of a session must have been rehearsed on the virtual bus.
UDS writes (WriteDataByIdentifier, RoutineControl, ECUReset, upload and download services) sit behind a second, stricter gate; clearing DTCs is its own request.
Listen-only connections, a team policy with noAgentSends and ECUDeck Free refuse agent sends before you are asked. Every allowed, denied or unanswered request is in the write log with the agent's name and reason.

Tools

Tool	What it does	Status
`list_connections`	Your saved connections with protocol (CAN or DoIP), role, adapter, bitrate, listen-only flag and the DBC files attached. Never secrets.	prototype
`list_adapters`	The CAN adapters the app can see on this computer and whether each one can confirm listen-only mode.	prototype
`read_frames`	Recent frames on an open bus, optionally filtered by identifier, with decoded signals when a DBC is attached. Bounded in count and time.	prototype
`decode_with_dbc`	Decodes given raw frames with one of the attached DBC files, for "what is this message?"	planned
`read_dtcs`	ReadDTCInformation (0x19) on a UDS connection: codes, status bytes and, where the ECU gives them, snapshot and extended data.	planned
`read_did`	ReadDataByIdentifier (0x22) for one or more identifiers, raw bytes plus the decoding you defined.	planned
`doip_discover`	Vehicle identification on the local network: VIN, logical addresses, gateway IP.	planned
`trace_search`	Searches a recorded trace by identifier, signal value or time window and returns matching frames with statistics.	planned
`send_frames`	Asks you to send one or more CAN frames. Pro; you allow it in ECUDeck.	prototype
`uds_request`	Asks you to send one UDS request (session control, TesterPresent, routine, write). Pro; you allow it in ECUDeck; writes behind the stricter gate.	planned
`clear_dtcs`	Asks you to run ClearDiagnosticInformation (0x14) on an ECU. Pro; you allow it in ECUDeck.	planned
`replay_trace`	Asks you to replay a recording onto a bus, with the frame count and duration shown first. Pro; you allow it in ECUDeck.	planned

Connect an agent

Settings → AI agents in ECUDeck shows the exact path of ecudeck-mcp and adds it to Claude Code, Cursor or Codex in one click. By hand, for Claude Code:

claude mcp add --scope user ecudeck -- /Applications/ECUDeck.app/Contents/MacOS/ecudeck-mcp

For Claude Desktop on macOS, in claude_desktop_config.json (Settings → Developer → Edit Config):

{
  "mcpServers": {
    "ecudeck": {
      "command": "/Applications/ECUDeck.app/Contents/MacOS/ecudeck-mcp",
      "args": []
    }
  }
}

On Windows:

{
  "mcpServers": {
    "ecudeck": {
      "command": "C:\\Program Files\\AKStudio\\ECUDeck\\ecudeck-mcp.exe",
      "args": []
    }
  }
}

For VS Code (GitHub Copilot agent mode), in .vscode/mcp.json, here with the Linux path:

{
  "servers": {
    "ecudeck": {
      "type": "stdio",
      "command": "/usr/bin/ecudeck-mcp",
      "args": []
    }
  }
}

What you can ask

"Which identifiers on the bench bus changed in the last 10 seconds, and which signals in my DBC moved?"
"Read the DTCs from the engine ECU and explain the status bytes."
"Find every frame in yesterday's trace where VehicleSpeed went above 50 km/h while the brake signal was on."

Privacy

The agent sees only what the MCP tools return. What it then sends to its own AI provider is governed by that agent and provider, not by ECUDeck. For a customer's vehicle, share only lab or bench connections with agents.

Questions: support@ecudeck.com