pymcuprog-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PYMCUPROG_TOOL | No | Debugger type (nedbg, pickit4, atmelice, snap, …). Default: any connected | |
| PYMCUPROG_DEVICE | Yes | Target device name (e.g. atmega4808, attiny416) | |
| PYMCUPROG_BAUDRATE | No | Baud rate for serial UPDI mode | 115200 |
| PYMCUPROG_SERIALPORT | No | Serial port for UART UPDI mode (e.g. /dev/ttyUSB0, COM3) | |
| PYMCUPROG_PROJECT_DIR | No | Default project directory for build_and_flash tool | |
| PYMCUPROG_SERIALNUMBER | No | USB serial number substring to select a specific tool |
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 |
|---|---|
| get_configA | Return the current server configuration read from environment variables. Call this first to confirm what device and tool are configured before running any programming operations. No hardware connection is required. |
| list_supported_devicesA | Return a sorted list of all device names supported by pymcuprog. No hardware connection is required. Use this to find the correct device name before calling any programming tool. |
| list_connected_toolsA | Return a list of Microchip USB HID debuggers currently attached to the host. Optionally filter by tool_name (e.g. 'nedbg', 'pickit4'). No device or session configuration is required. |
| read_tool_infoB | Read hardware and firmware information from the connected debugger. Returns a JSON object with fields such as fw_major, fw_minor, hw_rev, serial_number, and device_name. Requires a USB HID debugger; does not require a target device. |
| read_target_voltageA | Read the voltage on the target VCC pin as measured by the debugger. Returns the measured voltage as a float string (e.g. '3.298'). Requires a USB HID debugger with voltage measurement capability. Does not require a target device or programming session. |
| read_supply_voltageA | Read the debugger's onboard supply voltage setpoint. Returns the current setpoint as a float string. Requires a USB HID debugger with onboard supply capability (e.g. Curiosity Nano). |
| set_supply_voltageA | Set the debugger's onboard supply voltage output (e.g. 3.3 or 5.0). Returns 'OK' on success. Requires a USB HID debugger with onboard supply capability. WARNING: Ensure the target device supports the requested voltage before calling. |
| pingB | Read the device signature bytes to confirm communication with the target. Returns the device ID as a space-separated hex string (e.g. '0x1e 0x96 0x51'). Use this to verify the target is connected and responding before programming. |
| eraseB | Erase target device memory. memory='all' performs a chip erase (default). For AVR, chip erase does not erase EEPROM if the EESAVE fuse is set. Other valid memory values: 'flash', 'eeprom', 'user_row'. Returns 'OK' on success. Use erase before write_hex when the target is not blank. |
| write_hexA | Write an Intel HEX file to the target device. hexfile: absolute path to the .hex file on disk. erase_first: if True, performs a chip erase before writing. Default: False. verify_after: if True, reads back and verifies all written memory. Default: True. Returns 'OK' on success, raises an error if programming or verification fails. For the common case of a full firmware update, prefer the flash tool instead. |
| verify_hexA | Verify that target device memory matches an Intel HEX file. hexfile: absolute path to the .hex file on disk. Returns 'PASS' if memory matches, raises an error if it does not. Use after write_hex or to audit an already-programmed device. |
| read_memoryA | Read raw bytes from a target device memory area. memory: one of 'flash', 'eeprom', 'fuses', 'user_row', 'signatures', 'lockbits', 'boot_row'. offset: byte offset within the memory to start reading (default: 0). length: number of bytes to read; 0 means read to end of memory (default: 0). Returns a JSON object with keys 'memory', 'offset', 'length', and 'hex' where 'hex' is a space-separated hex byte string. |
| write_memoryA | Write raw bytes to a target device memory area. memory: memory area name (e.g. 'fuses', 'eeprom', 'user_row'). data_hex: bytes to write as a space-separated or 0x-prefixed hex string (e.g. '0xff 0x00 0xc8' or 'ff 00 c8'). offset: byte offset within the memory to start writing (default: 0). Returns 'OK' on success. Use for writing fuse bytes, EEPROM, or small memory regions. For full firmware images, prefer flash which handles address mapping. |
| hold_in_resetA | Hold the target device in reset. The device remains in reset until release_from_reset is called or the debugger is disconnected. Returns 'OK' on success. |
| release_from_resetC | Release the target device from reset, allowing it to start executing. Returns 'OK' on success. |
| build_and_flashB | Build a project with make and flash the result to the target device. project_dir: path to the directory containing the Makefile. Falls back to the PYMCUPROG_PROJECT_DIR environment variable if not provided. Runs 'make -C project_dir', finds the generated .hex file, then erases, writes, verifies, and releases the target. Returns 'OK' on success; raises with build output on compile failure. |
| flashC | Erase, write, and verify a hex file in one operation. This is the recommended way to program a device. It erases the target, writes the hex file, and verifies the result. hexfile: absolute path to the .hex file on disk. Returns 'OK' on success. |
| disconnectA | Close the persistent programming session. Call this to cleanly release the debugger connection, for example before unplugging the programmer or switching to a different target. Returns 'OK' on success. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lucasgerads/pymcuprog-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server