mBlock 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
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| project-listA | List .mblock/.sb3 projects under a folder. Start here to find a project file. |
| project-openC | Open a .mblock/.sb3 and summarize targets, extensions, block counts. |
| project-newA | Create a new .mblock from a template (blank, sprite_chase, mbot_forward, arduino_blink). |
| project-validateA | Validate block links (parent/next), unknown opcodes, missing x/y. Run before sharing or injecting. |
| project-attachA | Save default project/target (project.yaml) so later block tools can omit path/target. Run once per project. |
| project-archiveA | Zip a project (.mblock + .bak + profile) for sharing or backup. |
| project-duplicateA | Duplicate a project to a new path (safe way to try edits). |
| list_targetsB | List Stage/sprites/devices in a project. |
| list_blocksB | List blocks on a target (paginated). |
| get_blockB | Full JSON of one block + its catalog definition. |
| get_scriptB | Follow the next-chain from a hat block and return the ordered script. |
| list_opcodesA | Searchable block catalog (core + imported .mext). Filter by device and query. |
| describe_opcodeA | Inputs/fields/example for one opcode. Run before add_block to get params right. |
| import_mext_catalogA | Import a community .mext block catalog JSON so its opcodes become known (no more unknown warnings). |
| list_devicesA | Supported device profiles (sprite, mbot, cyberpi, arduino_uno, stage). |
| add_scriptB | Put a whole stack of blocks at once (file). First entry should be a hat. Handles next/parent/shadows + SUBSTACK. |
| add_blockA | Add a single block, optionally chained after afterId. Tip: describe_opcode first. |
| move_blockC | Move a top-level block to x/y. |
| set_block_fieldC | Set an input param or dropdown field on a block. |
| delete_blockA | Delete a block (+ its next-chain by default). Requires confirm:true. |
| add_variableC | Add a global variable to a target. |
| add_spriteC | Add a new sprite target. |
| app_statusA | Check if the mBlock 5 app bridge is connected (open app + drag in mblock-bridge.mext). |
| bridge-filesA | Write the mBlock-app bridge files (.mext + setup JS) to a folder so you can drag the .mext into the app. Run once. |
| app_put_scriptA | LIVE: put a script into the OPEN mBlock app via the bridge. Falls back to file hint if offline. |
| app_put_and_runA | LIVE combo (like upload-and-monitor): inject a script, run its hat, then read back a variable — new blocks to visible result in one call. |
| app_run_hatB | LIVE: run a hat block in the app (app.workspace.runBlocks). |
| app_get_varA | LIVE: read a global variable from the app workspace. |
| app_set_varC | LIVE: set a global variable in the app workspace. |
| app_get_codeA | LIVE: get transpiled Python/ArduinoC via device.getCode() in the app (like preprocess). |
| app_sensor_snapshotB | LIVE: non-blocking sensor/variable read (like monitor-snapshot). Pushes a state request and returns the latest bridge push + live var read. |
| list_costumesC | List costumes/backdrops of a target (like lib-examples: starter art inventory). |
| list_soundsC | List sounds of a target. |
| export_codeB | Export a human-readable listing of every script in the project (like export-binary/preprocess: review before running). |
| rename_targetA | Rename a sprite/device target (updates monitors' spriteName too). |
| doctorA | Health check for the whole mBlock setup: server, bridge app link, projects folder, bridge file. Run first when anything behaves oddly. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| new-project | Scaffold a project plan: device, blocks, variables, and test steps |
| fix-blocks-error | Systematic recipe for diagnosing a project-validate failure or broken script |
| migrate-device | Checklist for moving scripts between devices (e.g. sprite → mBot, mBot → CyberPi) |
| optimize-blocks | Recipe for shrinking a bloated or laggy script |
| sensor-debug | Sanity-check a sensor/robot wiring + reading plan before trusting it |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| mblock-config | Server version, projects root, bridge status |
| mblock-cheatsheet | Recommended tool order for AI agents: find → attach → inspect → edit → validate → run live |
| mblock-devices | Supported mBlock devices + opcode prefixes |
| mblock-opcodes | All known opcodes (core + imported .mext) |
TDQS
Scored across 36 tools
Each tool targets a distinct operation—project management, block manipulation, live app control, or asset listing. Overlaps like add_script vs add_block vs app_put_script are clearly differentiated by context (file-based vs live bridge). No two tools serve the same purpose.
Naming is inconsistent: some tools use hyphens (project-validate, project-list, bridge-files) while others use underscores (list_targets, get_block, add_script). Verb styles also vary (list, get, add, set, delete, move, rename, export, import, run, put). Not a predictable pattern.
With 36 tools, the server is over-scoped for an MCP surface. Even though it covers a broad domain, the count exceeds the 25+ threshold for 'too many'. Many tools are narrow (e.g., app_sensor_snapshot, list_costumes), contributing to bloat.
The server covers project lifecycle (new, open, duplicate, archive, validate), block/script editing (add, delete, move, set, get), and live app integration (put, run, read vars, get code). Minor gaps exist—no project deletion or block field retrieval—but core workflows are well-supported.