thonny-ai
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| THONNY_AI_PORT | No | Port for the HTTP bridge when Thonny is open. Default is 47821. | 47821 |
| THONNY_AI_PROJECT | No | Base folder for relative paths used by the MCP server. Default is the MCP server's working directory. | |
| THONNY_AI_SERIAL_PORT | No | Force a specific serial port (e.g., 'COM3') for direct serial connection. Auto-detected if not set. | |
| THONNY_AI_SERIAL_FALLBACK | No | Set to '0' to disable the serial fallback when Thonny is closed. Enabled by default. |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| statusA | How the board is reached right now: Thonny open/connected (interpreter, port, state, whether the user must approve actions) or direct serial. Call it first when unsure. |
| infoA | One-call board fact sheet: firmware and board name, CPU MHz, free/used RAM, free flash, unique id, Wi-Fi state, root files. Stops the program currently running. |
| execA | Run MicroPython code on the board and return its output (prints and tracebacks). When Thonny is open, the code appears in its shell highlighted as coming from the AI, exactly like a student typing it. Stops the program currently running first. timeout in seconds (default 10, max 300); on timeout the code is interrupted. For programs that loop forever (robots, sensor streams) use |
| startA | Launch a long-running program WITHOUT waiting for it to end (robot main loop, sensor logging…): pass |
| monitorA | Read what the running program prints, for up to |
| run_fileA | Run a .py file from the computer on the board without saving it there (path relative to the project directory). Default timeout 30 s. |
| lsC | List files on the board recursively, with sizes and free space. |
| readC | Read a file stored on the board. |
| writeB | Write a text file on the board (parent folders are created). |
| rmB | Delete a file or folder (recursively) on the board. |
| syncA | Upload a project folder (default 'src') to the board, sending only files whose SHA-256 differs from the board copy, then soft-reset so main.py restarts. Options: remote_dir (default '/'), force (upload everything), dry_run (only report), reset (default true). |
| interruptA | Stop the program running on the board (Ctrl-C, escalating to Stop/Restart in Thonny if needed). |
| resetA | Soft-reset the board (boot.py then main.py run again). |
| shellA | Read the end of Thonny's shell, i.e. what the user sees (Thonny must be open). |
| openA | Open a file from the computer in Thonny's editor (Thonny must be open). |
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 15 tools
The execution-related tools (exec, start, run_file, monitor) are closely related, but their descriptions clearly separate short-lived execution, long-running launch, output monitoring, and running a local file. A few side effects, like info also stopping the running program, could surprise agents, but overall the purposes are distinguishable.
Names mix imperative verbs (exec, start, read, write), noun commands (info, status, shell), Unix-style commands (ls, rm), and one verb_noun pair (run_file). There is no consistent naming pattern, though all names are short, lowercase, and readable.
Fifteen tools cover board execution, process control, filesystem management, and Thonny integration without feeling bloated. Some code-running tools could potentially be consolidated, but each addresses a distinct workflow.
The surface covers the main workflows: executing code, managing long-running processes, inspecting and modifying the board filesystem, and interacting with Thonny. Minor gaps exist, such as no direct way to run a file already stored on the board and text-only file writes.