t32-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| T32SYS | No | TRACE32 installation directory. Can also be set with the --sys command-line option. Defaults to C:\T32. | C:\T32 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
t32-mcp controls a Lauterbach TRACE32 debugger: PRACTICE commands and scripts, registers, memory, windows, trace and coverage analysis, and target run control.
Call session_open first. It connects only: it does not reset, download or run. Target setup is yours to write. session_status reports the demo directory; find a start-up script for your chip there, read it, adapt it, then run it with script. Demo scripts can reset the target or program flash.
A command that returns OK may not have taken effect. Read settings back with evaluate. Save raw trace with Trace.SAVE before analysing it.
If PowerView dies, call session_open again. Target state is lost, so rerun setup.
Numbers are hex; 32. with a dot is decimal. An address needs an access class: D:0x20000000 for data, P:0x08000000 for code, EAD:0x20000000 to read data while the target runs.
When you are not sure what a command is called or what it takes, ask manual before guessing.
Common windows and functions: Var.VALUE(a.b), Var.View %Open a, List.Mix for code, Frame.view /Locals /Caller for the stack, sYmbol.NAME(P:0x08000000) for the symbol at an address. Break.Set stops at code; Var.Break.Set a.b /Write stops on a write to a variable or struct member.
Other things TRACE32 does, which you will not stumble on: PERF profiles by sampling while the target keeps running: PERF.RESet, PERF.Mode PC, PERF.METHOD RealTime, PERF.Arm, then view PERF.ListFunc. TASK shows RTOS tasks after TASK.CONFIG with a file from demo/arm/kernel. PER shows peripheral registers. BMC counts core events. COVerage measures code coverage from trace.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| session_openA | Start or join a TRACE32 PowerView. Connects only: it does not reset, download or run. connection:
Installed targets: none found. TRACE32 directory: C:\T32. |
| session_statusA | Report the session: PowerView version, probe, license, CPU, target state, script depth, and the demo, manual and session directories. Works while an operation is blocked. |
| session_closeA | End the session. A PowerView started here quits, unless leave_running is true, which hands it to the user. An attached PowerView is only disconnected. |
| commandA | Run PRACTICE commands in order. Stops at the first failure and reports what ran. OK means TRACE32 accepted the command, so read settings back with evaluate. Use script for DO, session_close for QUIT, and run for Go when you need to wait for the target to stop. Commands can execute host programs through OS.Command. Wait for this reply before calling run: calls sent together run even if the setup failed. |
| evaluateA | Evaluate PRACTICE functions, for example Register(PC), Data.Long(D:0x20000000), Var.VALUE(counter), Trace.RECORDS(). Each expression succeeds or fails on its own, so pass everything you need in one call. An expression that calls a target function runs it on the target. |
| scriptA | Run a PRACTICE script from a file or from text and wait for it to end. Output from PRINT is returned. If it stops on an error the reply gives the failing command, and commands before it have already taken effect. A script that opens a dialog cannot continue, because nobody can click it. |
| viewA | Read a TRACE32 window as text, for example Register.view, Frame.view /Locals /Caller, Data.dump D:0x20000000++0xFF, Break.List, Trace.STATistic.Func, TASK.List.tasks, PER.view. Output past max_chars stays in a file, and its path is in the reply. Use full command names. Only display windows are accepted; for anything else use command with PRinTer.FILE and WinPrint. Give Trace.List a record range such as Trace.List (-1000.)--(-1.): a full list can be gigabytes. Reading PER windows can touch registers that have read side effects. |
| runA | Control the target: go, step, step_over, go_up, go_return, break. go waits until the target stops, also when it is already running. break stops the target now, wherever it is, so to wait for a breakpoint use go, not break. With until, go runs to that address and the reply says whether it got there. Reaching the deadline leaves the target running: nothing stops it for you. |
| manualA | Look something up in the TRACE32 manuals installed here. Give a name for its syntax, options and subcommands, or a few English words for candidates: Break.Set, Data.Long, PERF, flash programming. Add the target when a page differs by target: SYStem.MemAccess cortexm. An RTOS name alone lists its commands and setup: freertos. Needs no session. The manuals cover every target, so a name found here may not exist on yours: PRACTICE.CoMmanD.AVAILable() and PRACTICE.FUNCtion.AVAILable() tell. |
| operation_getA | Wait for an operation that replied Running, and return its final reply. Finished operations return the same reply again. |
| operation_cancelA | Cancel an operation. A queued one is dropped, a script is stopped, a run stops waiting and leaves the target running. A blocked command can only be ended with kill=true, which kills PowerView and loses target state. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
The tools have mostly distinct purposes: session lifecycle, command execution, expression evaluation, script running, window reading, target control, manual lookup, and async operation management. There is some conceptual overlap between command, script, evaluate, and run since all interact with the debugger, but the descriptions draw clear boundaries (e.g. use script for DO, read settings back with evaluate, use go not break to wait). An agent can reliably pick the right tool.
There are recognizable prefix groups (session_status/session_open/session_close, operation_get/operation_cancel), but the remaining tools are bare verbs or nouns (command, evaluate, script, view, run, manual) with no consistent verb_noun pattern. The conventions are mixed, though all names are readable and unambiguous in context.
Eleven tools is well within the ideal 3-15 range and each tool earns its place: session management, core execution primitives, manual lookup, and async operation handling. The surface is neither bloated nor thin for a debugger-control server.
The surface covers the full session lifecycle (open/status/close), command and script execution, expression evaluation, window reading, target control (go/step/break), manual lookup, and async operation get/cancel. Minor gaps exist in dedicated breakpoint, memory-write, and register tools, but these are largely reachable through command, evaluate, and view, so no major dead ends remain.