embedded-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Capabilities
Features and capabilities supported by this server
| 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 |
|---|---|
| list_serial_portsA | List the serial ports currently available on this machine. Use this first to find out which port your board is on (e.g. "COM5" on
Windows, "/dev/ttyACM0" on Linux). The other tools all take a Returns one entry per port with its device name and a human description. |
| read_serialA | Read whatever the device prints on This opens the port, listens passively, and gives back everything it saw. Great for "what is my firmware logging right now?". Args: port: Serial port name, e.g. "COM5" or "/dev/ttyACM0". baudrate: Bits per second. Must match your firmware (default 115200). seconds: How long to listen. Capped at 30s. |
| send_commandA | Send Writes the command (plus a line ending) to the port, then listens for the
response for Args: port: Serial port name. command: The text to send (line ending added automatically). baudrate: Bits per second (default 115200). reply_seconds: How long to wait for the reply. Capped at 30s. line_ending: Appended to the command. "\n", "\r\n" or "" . |
| decode_registerA | Decode a raw register value into its named bit-fields. A constant pain in embedded work: you read a register as Args: value: The raw register value (e.g. 0x4002). fields: A list of field descriptors. Each is either: {"name": "EN", "bit": 0} -> single bit {"name": "PRESC", "msb": 5, "lsb": 2} -> bit range [msb:lsb] width: Register width in bits (8, 16, 32...). Used only for display. Returns the binary view plus each field's extracted value. |
| decode_register_svdA | Decode a register by name using a CMSIS-SVD chip description file. Instead of typing out the bit map by hand (as Example: decode_register_svd(0x4002, "STM32F407.svd", "RCC", "CR") Args: value: The raw register value you read back. svd_path: Path to a CMSIS-SVD file on this machine. peripheral: Peripheral name as in the SVD, e.g. "RCC". register: Register name as in the SVD, e.g. "CR". width: Register width in bits for display (default 32). |
| list_flashersA | Report which firmware-flashing tools are installed on this machine. Call this before |
| flash_firmwareA | Flash a firmware image onto the connected board. DESTRUCTIVE: this overwrites the flash of whatever board is connected. For
safety it defaults to Args: firmware_path: Path to the firmware (.bin for st-flash; .elf for probe-rs/openocd). tool: "auto" (pick the first installed) or "st-flash" / "probe-rs" / "openocd". address: Flash address for st-flash (default STM32 0x08000000). chip: Chip name for probe-rs, e.g. "STM32F407VG". openocd_target: OpenOCD target cfg, e.g. "target/stm32f4x.cfg". dry_run: If True (default), return the command instead of running it. timeout_seconds: Max time to wait when actually flashing (capped at 600s). |
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
- 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/atillab1/embedded-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server