Keil5 MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KEIL_UV4_PATH | No | Path to the Keil MDK UV4.exe executable. If not set, the server will attempt to use the default path from configuration or report an error. | |
| KEIL_PROJECT_DIR | No | Default directory for Keil projects. Used by tools like discover_keil_projects. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| build_projectA | Build a Keil project with UV4 -b (or -r rebuild / -c clean). Args: project: path to .uvprojx (absolute or relative to default_project_dir) target: target name (default: first target in project) timeout_seconds: build timeout (default 120) stream_progress: tail the log for realtime progress (percent/phase) clean: run UV4 -c instead of -b rebuild: run UV4 -r (full rebuild) instead of -b Returns: {status: ok|error|canceled|not_found, returncode, build_log, errors[], summary, progress?} |
| build_progress_statusB | Query the live progress of a running build. |
| build_cancelC | Request cancellation of a running build. |
| parse_build_errorsA | Parse a UV4 build log into structured errors/warnings (blueprint §7.2). Args: log_path: path to build log file, OR log_content: raw log text Returns: {errors[], warnings[], summary{success, errors, warnings, code_size, ...}} |
| explain_build_errorB | Map a Keil/armclang error code to explanation, causes and fixes. |
| source_readA | Read a source file with line numbers (auto backup not needed; read-only). |
| source_editA | Edit a source file; original is automatically backed up to .keil-mcp-backups/. Args: file: path to source file start_line / end_line: 1-based inclusive line range to replace new_content: replacement text (can be multi-line) |
| source_searchA | Search source files in the project directory. Args: pattern: text or regex pattern path: directory to search (default: default_project_dir or cwd) files: optional explicit file list (relative to path) regex: treat pattern as a regular expression |
| uv4_debug_sessionA | Run an official Keil debug session via UV4 -d + a generated .ini script. The debugger runs headless: sets a breakpoint, resets, runs, optionally steps, and prints variable values. Output is captured from the session log. Args: project: path to .uvprojx target: target name (default first target) ini_path: custom .ini script path (overrides generated script) reset: reset target before running breakpoint: symbol/line to break at ("" = none) steps: extra single-step count after hitting the breakpoint dump_vars: variable names to print (e.g. ["i", "adc_value"]) timeout_seconds: session timeout |
| uv4_debug_ddeC | Read the output of a UV4 -d debug session (session output channel). |
| keil_doctorB | Check the Keil environment: UV4.exe, pyocd, packs, config. |
| discover_keil_projectsB | Discover *.uvprojx Keil projects under a directory. |
| configure_keil_projectA | Parse a Keil project: targets, device, pack, groups, source files. Use before building to pick the right target / confirm the device. |
| flash_firmwareA | Flash firmware to the target chip. Preferred path: UV4 -f (Keil official flash download, uses the project's configured Flash algorithm). Fallback: pyocd load . Requires confirm=True (persistent destructive operation). Args: project: .uvprojx path (for UV4 -f) — required unless image is given target: target name for UV4 -f image: firmware image (axf/hex/bin) for the pyocd path backend: "uv4" | "pyocd" | "auto" probe_id: pyOCD probe unique id (optional) confirm: MUST be True to actually flash |
| erase_flashA | Erase the target chip flash (pyocd erase -c). Requires confirm=True. |
| verify_flashB | Verify firmware on chip against an image (pyocd verify). |
| probe_connectC | Connect to a debug probe via pyOCD (auto-detect or by unique id). |
| probe_disconnectA | Disconnect the probe (releases it for UV4 -f flash path). |
| probe_haltC | Halt the target. |
| probe_resumeC | Resume the target. |
| probe_stepC | Single-step the target. |
| set_breakpointC | Set a hardware breakpoint by symbol name or address. |
| continue_targetB | Continue the target until the next breakpoint. |
| probe_read_registersB | Read core registers (r0-r15, xpsr, sp, lr, pc). |
| probe_read_memoryC | Read memory at address (bytes). |
| read_rtt_logA | Read recent SEGGER RTT log output from the target (if RTT is running). |
| keil_versionA | Return the keil5-mcp server version and available tool count. |
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 27 tools
Most tools target clearly distinct operations (build, source, flash, probe control), and the descriptions help separate them. Minor ambiguity exists between 'probe_resume' and 'continue_target' and between 'parse_build_errors' and 'explain_build_error', but these are usable with the provided docs.
The majority follow a verb_noun pattern like 'build_project', 'source_edit', and 'probe_halt', but there are notable deviations such as 'uv4_debug_dde', 'keil_doctor', and 'build_progress_status'. Names are generally readable but the mixed styles prevent a higher score.
With 27 tools, the server exceeds the 25+ threshold where tool count becomes heavy for an agent to navigate. The tools cover many subdomains, but several low-level probe primitives and debug-session helpers could be consolidated or omitted.
The server covers build, source editing, flashing, and basic debugging well. However, obvious lifecycle gaps exist: breakpoints can be set but not listed/deleted, memory/registers are read-only, and there is no standalone reset target operation or project creation/configuration update capability.