stm32-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| stm32_doctorA | Reports resolved paths, versions, installed FW packages, and every problem found (missing package, non-ASCII home path, missing ST-LINK driver). Run this first; every other tool should suggest it on failure. |
| stm32_create_projectA | Args: name, mcu (e.g. STM32F103C8Tx), path, pins[] ({pin, mode, label}), clock ({hse_hz, sysclk_hz} or a named preset), debug (swd/jtag/none). Writes a valid .ioc and generates the CubeIDE project. |
| stm32_configure_pinsA | Patches pin config in an existing .ioc and regenerates. Idempotent. |
| stm32_generate_codeA | Runs CubeMX config load + project generate on an existing .ioc. |
| stm32_patch_user_codeA | Args: file, section (e.g. PD, 2, WHILE, 4), content, mode (replace/append). Writes only between /* USER CODE BEGIN x / and / USER CODE END x */. Must fail loudly if the markers are missing or unbalanced, and must never touch generated init functions. |
| stm32_buildA | Headless build. Returns structured diagnostics: {severity, file, line, column, message} parsed out of the GCC output, plus a short summary and the flash/RAM usage from the size output. Do not dump raw logs into the model context. |
| stm32_cleanA | Clean build artifacts. Flashing hardware and deleting files require an explicit confirm: true argument. Default is refuse. |
| stm32_flashC | STM32_Programmer_CLI -c port=SWD -w -rst. Requires confirm: true. Default is refuse. |
| stm32_read_projectA | Summarises an existing project: MCU, clock tree, configured pins, enabled peripherals, whether FreeRTOS is on. Reads the .ioc, not the generated code. |
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 9 tools
Each tool maps to a distinct lifecycle phase: diagnose, create, configure pins, generate, patch user code, build, clean, flash, and read project state. Even create_project and generate_code are clearly separated by whether an .ioc already exists, so an agent can select appropriately.
All tools share a consistent stm32_ prefix and use snake_case, with the majority following verb_noun pattern (create_project, configure_pins, generate_code, patch_user_code, read_project). The stm32_doctor name is the main deviation, since it is noun-like rather than verb_object, but it remains recognizable and consistent with the set's style.
The set has 9 tools, which is well within the ideal range and matches the server's stated purpose of covering an STM32 project workflow from diagnostics through flashing. Each tool has a clear role and none feel redundant or superficial.
The tool surface covers the main project lifecycle well: create, configure, generate, patch, build, clean, flash, and read state. A minor gap is that clock or peripheral configuration cannot be changed after project creation except through existing pin configuration, and there is no explicit erase/reset tool, but these are workable limitations.