cspy-mcp: MCP server for IAR C-SPY

An MCP server, iar-cspy-mcp, that exposes
the IAR C-SPY debugger, and the Embedded Workbench project and option
services, to AI assistants (Claude Code, Claude Desktop, VS Code Copilot, ...)
as tools. It drives the backend over its Thrift interfaces, on a simulator or
real hardware.

The server is a thin layer over the iar-cspy
Python API: each tool parses its arguments, calls the API, and returns plain
JSON. For scripts and pytest hardware-in-the-loop tests, use that API
directly.

Licensed under the MIT License.

Getting started

Install the server (it brings the iar-cspy API along) and point it at your
IAR installation, the directory with common/bin under it:

pip install "iar-cspy-mcp @ git+https://github.com/iarsystems/cspy-mcp"
iar-cspy-mcp --iar-path /opt/iar/ewarm       # or: python -m iar_cspy_mcp

To pin a version, add @<branch, tag or commit> after the repository URL.
Normally your MCP client starts the server for you; see below.

Add it to your MCP client

All examples use managed mode: the server starts the backend itself from an
IAR installation or build stage (the directory with common/bin under it).
Adjust the path to your machine. See Backend modes
for what managed and standalone mode do.

Claude Code: .mcp.json in your project (or ~/.claude.json), or
claude mcp add cspy-debugger -- iar-cspy-mcp --iar-path /opt/iar/ewarm:

{
  "mcpServers": {
    "cspy-debugger": {
      "command": "iar-cspy-mcp",
      "args": ["--iar-path", "/opt/iar/ewarm"]
    }
  }
}

Claude Desktop: the same mcpServers block in claude_desktop_config.json
(Settings > Developer > Edit Config).

VS Code Copilot: .vscode/mcp.json (or MCP: Add Server):

{
  "servers": {
    "cspy-debugger": {
      "type": "stdio",
      "command": "iar-cspy-mcp",
      "args": ["--iar-path", "C:\\iar\\ewarm-9.60"]
    }
  }
}

If iar-cspy-mcp is not on the client's PATH, use the virtualenv's Python:
"command": "/abs/path/.venv/bin/python", "args": ["-m", "iar_cspy_mcp", ...].
From a checkout without installing, run_headless.sh <iar-path> does the same
over stdio (see Helper scripts).

An already-running backend (standalone mode): replace --iar-path with
its service registry:

"args": ["--registry-host", "127.0.0.1", "--registry-port", "51926"]

Requirements

Python 3.10+ on Linux or Windows, and either an IAR installation or an
already-running backend to connect to. The installation is the directory with
common/bin under it (for example IAR Embedded Workbench for Arm), and it
needs to ship CSpyServer2; the backend is then started for you. The project
and options tools also need IarServiceLauncher.

The minimum required IAR product version depends on the architecture:

Some functionality may only be available on newer versions;
we recommend using the latest IAR product version for your architecture, if possible.

Backend modes

• managed (default): given an IAR installation (--iar-path or
  IAR_INSTALL_PATH), the server starts IarServiceLauncher, which owns the
  service registry and hosts the IDE services, and a CSpyServer2 that joins
  that registry with -registry <port>, so the project_*/options_* tools
  work alongside the debugger ones. It supervises both and restarts them when
  they fail. CSpyServer2 supports one debug session per process, so every
  session gets a fresh one. Installations without the launcher, or
  --no-ide-services, run CSpyServer2 alone, without the project and options
  tools.
• standalone: --registry-host/--registry-port (or
  THRIFT_REGISTRY_PORT) connect to the registry of a backend someone else
  runs, such as a Thrift-enabled iaride or a hand-started
  CSpyServer2/IarServiceLauncher. The port is that of the service registry,
  not of the debugger service itself. Nothing is started or stopped.

See docs/ide-services.md for the IDE services, and
the backend notes
for known backend behavior.

Command line

Every option also has an environment variable; see
.env.example. MCP_TRANSPORT=streamable-http,
MCP_HOST and MCP_PORT select the network transport without --web;
MCP_HOST=0.0.0.0 listens on all interfaces, which exposes the debugger to
the network.

On stdio the server logs every backend RPC to stderr ([thrift] call ...),
which MCP hosts collect as server logs; stdout carries only the protocol.

Helper scripts (Linux/macOS)

Bash wrappers that run the server from a checkout without installing it. Each
takes the IAR path as its first argument or from IAR_INSTALL_PATH, and uses
.venv/bin/python3 when present.

NO_IDE_SERVICES=1 and THRIFT_IDE_SERVICES=projectmanager restrict what
the managed backend hosts. On Windows, run iar-cspy-mcp (or
python -m iar_cspy_mcp) directly; scripts/run_validation.ps1 -IarPath <path>
runs the unit and live tests.

Tools

Each tool's description (what the MCP client shows the model) documents its
arguments. The raw RPC tools take args_json: a JSON array for positional
arguments ("[123, \"abc\"]"), an object for keyword arguments, with
structs as objects and enums by name. Headless backends may not publish
instruction trace list windows; listwindow_list_services("") shows what is
registered before you read rows.

Response envelope and errors

The lifecycle, status, wait, project and options tools return
{"ok": bool, "tool": name, "data": {...}, "error": null | {...}}. Expected
negative outcomes (a timeout, a failed build, rejected option values) are
ok: false with a machine-readable error.code (TIMEOUT, BUILD_FAILED,
OPTION_VERIFICATION_FAILED, ...) rather than a tool error.
debugger_error_taxonomy() lists the codes. When a failure looks like a
backend crash, details.backend_diagnostics carries the backend's recent
output.

Most debugger tools need a started session and refuse with an explicit
message otherwise.

Playbooks

These are compact flows for tool-using agents.

Start a session: debugger_configure_and_start_session(launch_json), then
debugger_session_status(); continue when data.started is true.
launch_json is one entry of a C-SPY VS Code launch.json (a whole file with
configurations also works: the first one is used). In managed mode every
call starts from a fresh backend process. The session runs to the
configuration's stopOnSymbol; data.ranToSymbol reports whether it got there.

From an Embedded Workbench project: project_load_workspace(path), then
project_build() (a failed build is ok: false with data.output_tail),
then project_configure_and_start_debug(). No launch.json is needed.

Run and wait: debugger_go_and_wait_for_core_state(desired_state=0, timeout_ms=5000).
Core states are 0 = stopped, 1 = running, 2 = sleeping, 3 = unknown, 4 = no power.
On error.code == "TIMEOUT", retry with a longer timeout or call debugger_stop().

Breakpoints: breakpoints_set_on_source("/abs/path/main.c", 82),
breakpoints_set_code("main", mode="hardware"),
breakpoints_set_data("g_state", 3) (2/3/4 = read/write/read-write) and
breakpoints_set_log("phase_step", "phase {g_phase}") pick the breakpoint
category for the session's driver, so they also work on hardware probes;
breakpoints_get_modes() lists the driver's modes and debugger_get_log()
returns log breakpoint output. breakpoints_set_on_ule("main", 1) leaves
the category to the backend (1 = code, 2/3/4 watchpoints). ULEs are
expressions (main, func+4), addresses (0x100), or full-form source
locations ({/abs/path/file.c}.123.1); main() and file.c:123 shorthand
are backend-dependent. breakpoints_set_from_descriptor only takes
descriptors returned by breakpoints_get_all().

Probe before advanced calls: debugger_capabilities() returns the backend
mode, services, debugger methods, and any probe errors.

Recover: debugger_strict_cleanup(reset_target=true), inspect
data.errors[*].details.backend_diagnostics, then start again.

Non-intrusive attach: use a launch configuration with "request": "attach",
"attachToTarget": true, "leaveTargetRunning": true and all downloads
suppressed. Check debugger_get_core_state before deciding to call
debugger_stop(), and avoid debugger_reset().

Options: options_create_session → options_get_category_tree →
options_get_option_tree → options_update_state → options_commit or
options_destroy_session; see docs/ide-services.md.
For plain option reading and writing, projectmanager_call("GetOptionsForConfiguration", ...)
needs no session.

When a tool cannot do it: for multi-step work such as loops, conditional
logic, or collecting a lot of state, writing a short script against the
iar_cspy Python API is often simpler and faster than many
tool calls. Its objects mirror these tools.

How it works

 MCP client ──MCP──▶ iar-cspy-mcp ──▶ iar-cspy ──Thrift──▶ service registry ──▶ CSpyServer2  (debugger, breakpoints, memory, ...)
                                                                         └─▶ IarServiceLauncher (ProjectManager, OptionsService)

iar-cspy resolves every service through the registry, supervises the
managed processes, and hosts the callback services the backend expects from
a frontend (debug events, terminal I/O, list window notifications).

Repository layout

src/iar_cspy_mcp/    the server: _app.py (app, client, envelope), cli.py, server.py
  tools/             one module of MCP tools per area
tests/               tool tests (against iar_cspy.testing fakes) and live tests
examples/
  firmware/          Cortex-M3 simulator program + launch.json used by the live tests
  mcp/               MCP client configs and a stdio protocol client
docs/                IDE services
scripts/             run_validation.ps1: unit and live tests on Windows
mcp_thrift_server/   deprecated shim for the server's old module name (see below)
run_headless.sh, run_web.sh, run_iaride.sh   start the server from a checkout (Linux/macOS)

Development

pip install -r requirements-dev.txt                 # the server editable + pytest
pip install -e ../cspy-py                           # optional, afterwards: your checkout of iar-cspy
pytest                                              # unit tests; live tests skip without a backend
pytest -m live --cspy-iar-path=/opt/iar/ewarm       # live tests, managed backend
pytest -m live --cspy-cspyserver2=/path/CSpyServer2 # live tests, CSpyServer2 only

The tools live in src/iar_cspy_mcp/tools/, one module per area. Keep them
thin: argument parsing and result shaping belong here, behavior belongs in
iar_cspy. The tool tests run against iar_cspy.testing.fake_client(), and
tests/test_live.py covers a real backend on the bundled firmware
(examples/firmware), including a full MCP stdio round trip. CI
(.github/workflows/ci.yml) runs the unit tests on Python 3.10-3.12, builds
the distribution, and runs the live tests against the public cxarm toolchain.

python -m mcp_thrift_server, the server's old name, still works from a
checkout (with a deprecation notice), so existing MCP client configs keep
working. Point them at iar-cspy-mcp / python -m iar_cspy_mcp instead.