![\"DOOM](\"https://raw.githubusercontent.com/eoinjordan/doom-godmode/main/assets/header.png\")
This one started as a question I couldn't let go of: could I turn a real place — a named street, a famous building, your school — into a playable Doom level, with no npm dependencies at all? The answer turned out to be yes, and the pipeline is simpler than it sounds once you stop fighting a 1993 game engine.
doom-osm-godmode (on npm as doom-osm-godmode) does this:
You load the PWAD into GZDoom and walk through a spatial approximation of wherever you asked for.
npx doom-osm-godmode build-place \"Colosseum, Rome, Italy\" --radius 450That's the whole install. No npm install — there are no dependencies. Just Node 20 built-ins: fs, path, fetch, Buffer. I kept it that way on purpose: a tool with zero supply chain is a tool a teacher can run on a locked-down school laptop without a security conversation.
Getting GZDoom UDMF geometry right is not obvious. Doom's 2.5D engine has rules that aren't enforced at the file-format level but absolutely are enforced at render time — you get visual corruption instead of an error message, which is a much worse way to find out you were wrong.
The 1.2.0 release fixed most of them the hard way. Wall flickering from duplicate linedefs at cross junctions: fixed by replacing four overlapping rectangles with a single 12-vertex polygon. Invisible mid-walls on two-sided linedefs between same-floor sectors: fixed with wrapmidtex = true and blocking = true. Sky bleed at ceiling edges. Player stuck in zero-height pillar sectors, replaced with Thing type 30, the tall green column. Each one was its own debugging session.
So I wrote a validator. It catches 12 classes of these problems before GZDoom ever sees the file, plus a standalone diagnostic script for when the validator passes but something still looks wrong. That's the same instinct behind everything I build for learners: make the failure inspectable instead of mysterious.
The OSM pipeline generates rooms from feature polygons automatically, which is great, but it produces blocky results for architecturally distinct buildings. So 1.2.0 added a hand-crafted example: Galway Cathedral. Cross-shaped floor plan as a 12-vertex polygon, green copper dome, twin towers, spire, raised chancel, nave pillars as Thing objects rather than sectors (sectors with floor=ceiling confuse the GZDoom node builder), teleporter-based catacombs. It lives in scripts/build-galway-cathedral.js as a reference for anyone who wants to build from a real floor plan rather than pulling from OSM.
The piece I'm most fond of is the automated playtest. npm run playtest runs an agent that builds a WAD and validates it without ever opening GZDoom — vertex references, sector references, one-sided versus two-sided linedef consistency — and produces a pass/fail report. It runs in CI on every push, so a regression in the geometry pipeline gets caught immediately instead of showing up as visual corruption hours later.
This is the pattern I keep coming back to: a tool is a single capability (build a WAD); a skill is the bounded, testable loop around it (build → validate → diagnose → fix → repeat). The AGENTS.md spells that loop out so an agent iterates on UDMF geometry the same disciplined way you'd iterate on any embedded target.
git clone https://github.com/eoinjordan/doom-godmode.git\ncd doom-godmode\nnpm test\nnpm run demoThe demo runs offline from a bundled GeoJSON, so it works without touching the OSM APIs — handy for a classroom with no open internet. The Freedoom IWAD installer (node scripts/install-freedoom.js) pulls a free IWAD so nobody needs a commercial Doom copy to play the output.
It turns out real cities make good Doom levels — the street grid does most of the level design for you. The only genuinely hard part was teaching a 30-year-old renderer to behave, and honestly that was the fun part.
If you could walk through one real place as a Doom level, what would you pick? I'm tempted to do a whole campus next.
Minecraft is where a lot of kids do their first real building. So I wanted to point an agent at a real place — not have it hand-place a recreation, but pull a layout straight from the map data — and have it built in their world. That's what minecraft-mcp does. You name an area (a park, a city block, a campus) and the planner geocodes it through OpenStreetMap, converts the coordinates into Minecraft block positions, and generates Bedrock-safe command plans an agent can execute.
The harder part was making that reliable enough to actually put in front of someone. Bedrock client support for live automation is inconsistent across versions; what you get from /connect and the WebSocket bridge varies by client build. So the architecture splits in two:
/function agentic_builder/... commands that run stably on any Bedrock client, no /connect required.The split is the point. The server does the AI-assisted planning; the behavior pack gives you a dependable execution path even when the live bridge isn't available. You can build on PC and upload the world to a Realm for Switch play — which matters when the device in a kid's hands isn't the device you developed on.
The default model path is Ollama: run a local model, no API key, no cloud dependency. OpenRouter and Groq are configured as fallbacks for constrained devices where a local model isn't practical. A Pi 4 with 4 GB can run a small quantised model via Ollama and serve as both the MCP host and the planning backend for a whole classroom. That's deliberate — plenty of school networks block external API calls, and \"it needs an internet API key\" is where a lot of good lessons quietly die.
The MCP surface is intentionally narrow: tools for planning (define area, add landmark, generate command plan), resources for inspecting state (current map, landmark list), and prompts for guided workflows. All state is explicit — planner state and a MAP.md file are the source of truth, not in-memory data that vanishes on restart.
I've standardised agent skill files across my MCP projects — reusable, multi-step workflows that encode the decisions a practitioner would actually make. The minecraft-mcp repo mirrors them for Claude, OpenCode, generic agents, and Clawdbot, all with the same scope and safety rules. The rule of thumb is the one I described in the Edge Impulse MCP post: skills are what agents reach for first, tools are what skills call, and raw tool sequences without skill scaffolding are the wrong way to drive the server. Skills make agentic loops predictable; tools without skills produce creative but unreliable results.
Safety note: treat an MCP server like executable code. start:safe binds to localhost only, and you should keep it pointed at a throwaway world, not the build you've spent six months on. Agents are confident; worlds are cheap to back up.git clone https://github.com/eoinjordan/minecraft-mcp.git\ncd minecraft-mcp\nnpm install\nnpm run start:safeThe newcomer path: start the server, create a landmark or area through the HTTP API at http://127.0.0.1:3093, install the Bedrock behavior pack with npm run install:bedrock, enable it in your world, and run /function agentic_builder/info. From there the agent handles the planning and the behavior pack handles the execution. For the real-world path, any place name works: create_area(\"Trinity College Dublin\", radius_meters=800) and the planner does the rest.
The OSM-as-source-of-truth trick started with my Doom level generator. Minecraft turned out to be the gentler target — blocks are already a grid, so there's no 2.5D engine waiting to punish you for a malformed sector.
If you teach with Minecraft, what real place would your students want to walk into first — their town, their school, somewhere they'll never get to visit?
Go into any university lab that touches embedded systems, robotics, or maker-adjacent engineering and look at the shelves. You'll find the same hardware over and over: Raspberry Pis in various generations, an NVIDIA Jetson or two, a drawer of Arduino Unos and Nanos, some LEGO Mindstorms kits in varying states of completeness, a few micro:bits, maybe a box of ESP32 dev boards. Some of it bought last year, some of it bought eight years ago.
This is the hardware students actually learn on. It's what's affordable, what IT will approve, what has enough documentation to survive a semester, and what gets donated and kept when budgets get cut. It's not going away.
What bothers me is the assumption — implicit in most tooling decisions — that agentic AI, MCP servers, and the current wave of AI-assisted development are for the new stuff. That they're for cloud-connected enterprise hardware, not for the Arduino Nano 33 BLE in the component drawer.
That assumption is wrong, and it leaves students behind.
Let me be specific, because the hardware matters.
Arduino. The Uno is a 16 MHz AVR with 2 KB RAM. Agentic AI can't run on it. But it absolutely can run with it. An MCP server that validates, compiles, and flashes Arduino sketches — using the Arduino CLI under the hood — turns any LLM into a tool that can iterate on embedded code against real hardware. Describe the behaviour you want, generate the sketch, validate it compiles for your FQBN, flash, watch the serial output, iterate. That's a meaningful agentic loop and it runs on a five-year-old laptop wired to a three-pound board. My Arduino MCP server does exactly this.
Raspberry Pi. From a 3B+ upward, these are real Linux machines. They run Ollama. They run small quantised models. They can be both the host of the MCP server and the inference target. A student with a Pi 4 has a complete agentic stack for basically nothing — local LLM, tool server, hardware target, all on one board. The gap is documentation and scaffolding, not compute.
NVIDIA Jetson. The Orin Nano starts around $250 and has enough CUDA to run proper vision models locally. The ecosystem has TensorRT, DeepStream, and Triton — production inference tooling, on hardware a university can stock. The missing piece is agentic scaffolding that meets students where they are, rather than assuming they've already set up Kubernetes.
LEGO Mindstorms and WeDo. EV3, NXT, SPIKE Prime, Robot Inventor, WeDo 2.0 — all programmable hardware with real sensors and actuators, and all with enough open-source firmware and protocol support to be first-class agentic AI targets. The Mindstorms Robot Creator is my attempt at a unified code-generation and connection layer for the whole family, exposed to agents as MCP tools.
micro:bit. V2 has a microphone, speaker, accelerometer, and BLE. The micro:bit MCP server handles firmware generation and flashing. It's built for exactly the case where someone has thirty micro:bits and no budget for anything else — enough to teach embedded sensing, wireless comms, and agentic code generation in one session.
It isn't that the hardware can't do it. It's that the agentic tooling layer assumes you're starting fresh. Every major AI coding tool defaults to \"set up a new project.\" Every tutorial starts with \"first, provision your cloud instance.\"
Nobody at a resource-constrained university is provisioning cloud instances. They're plugging things into USB ports and hoping the driver works.
What they need is MCP servers that speak the language of the hardware they already have: Arduino CLI for Arduino boards, Web Serial for LEGO hubs, OpenOCD for SWD-accessible microcontrollers. The Edge Impulse agentic work showed what this looks like at the ML layer — tools that are thin wrappers over real actions, skills that encode the multi-step workflows a practitioner would follow, outputs that are inspectable rather than opaque. The same pattern works for embedded toolchains.
If I were setting up a lab today for students who need to learn agentic AI with real hardware, this is the stack I'd build:
The Jetson Orin Nano is the step up when you need vision — proper camera pipeline, TensorRT quantised inference, enough RAM for a vision-language model. But that's not the starting point. The starting point is what's already there.
\"Support\" for hardware usually means: it works, there's a tutorial, there's a forum. That's fine for getting started. What students need beyond that is to be enabled — to reach for the latest tools and have them work with the hardware in their hands, not the hardware in some vendor's reference design.
That means MCP servers that speak embedded protocols. It means code generators that know what 2 KB of RAM implies. It means agentic loops that can flash firmware, read serial output, and iterate — not just write code and hand it back. It means block-based interfaces that work for a ten-year-old with a WeDo kit and Python generation that works for a student writing their first embedded ML pipeline on the same hardware.
The work isn't glamorous. Writing an MCP server for a 25-year-old serial protocol is not the kind of thing that goes on a keynote slide. But it's the difference between hardware that sits on a shelf for another decade and hardware that teaches the next generation of embedded engineers how to work with AI.
The hardware is already there. The software support is the work.
If you teach or run a club or lab: what's on your shelf that you wish an agent could already drive? That list is basically my backlog — tell me what to build next.
In my shelf-hardware piece I argued that the Arduino in the component drawer is a first-class agentic target, not a relic. This is the tool that makes that true: arduino-mcp (on npm as eoinedge-arduino-mcp).
An Arduino Uno is a 16 MHz AVR with 2 KB of RAM. You're not running a language model on it. But you can wrap a clean loop around it: describe the behaviour you want, let an agent generate the sketch, validate it compiles for your board, build the binary, flash, read the serial output, and iterate. That loop is the whole game, and arduino-mcp is the bit in the middle that makes it dependable.
The server is a thin, honest wrapper over arduino-cli. Three endpoints, nothing clever hidden:
/health — is the toolchain present and ready/validate — does this sketch compile for the target FQBN, with the errors an agent can act on/build — compile and export the binaryIt defaults to the Arduino Nano 33 BLE (configurable via FQBN), auto-installs missing Arduino cores so the agent isn't blocked on a manual setup step, listens on port 3080, and allows a generous 600-second compile timeout because real boards and real cores are slow and that's fine.
The reason this matters for classrooms is where it runs. There's a multi-platform Docker image (linux/amd64 and linux/arm64), so a Raspberry Pi can be the whole rig: the MCP host, the build server, and — with Ollama alongside it — the model too. A student plugs a board into the Pi's USB port and has a complete, offline, agentic embedded stack for the price of a board and a Pi.
Safety note: a build server that compiles arbitrary code is exactly as powerful as it sounds. Run it in the Docker container, keep its filesystem access scoped to a sketch directory, and don't expose port 3080 beyond the machine that needs it.
This follows the same rule as the rest of my MCP work: a tool is one capability (validate a sketch); a skill is the bounded workflow built from tools (generate → validate → fix the compile errors → build → flash → read serial → iterate). When you give the agent skills instead of raw tools, the loop stays predictable and the student can read exactly what happened at each step. That inspectability is the educational point — the failure messages are a feature, not noise to hide.
npm install -g eoinedge-arduino-mcp\n# or run the container, then point your agent at port 3080From there the agent can validate against your FQBN, build a binary, and hand you serial output to reason about — the same flash-and-observe rhythm an embedded engineer already lives in, just with a collaborator who never gets bored of recompiling.
If you've got a drawer of Arduinos gathering dust, what's the first thing you'd wire an agent up to — a sensor logger, a blink-debugger, a little robot? Tell me and I'll make sure the skills cover it.
The BBC micro:bit is, for a lot of kids, the first computer they ever program that does something physical — a light, a sound, a message flung across the room over radio. There are millions of them in schools. So when I think about where agentic AI should meet learners, a drawer of thirty micro:bits is close to the top of the list. That's what microbit-mcp (on npm as microbit-claude-mcp) is for.
It's an MCP server for BBC micro:bit v2 projects built on the CODAL toolchain. An agent can read and write the project's source/main.cpp, validate the project layout, run build.py, and produce a flashable MICROBIT.hex — the same artifact you'd drag onto the board's USB drive.
Block editors are a brilliant on-ramp — I've written before about how visual, low-code tools recenter programming on logic and ideas instead of semicolons. But the micro:bit's real superpower in a classroom is that the same board runs serious C++. An agent that can generate and regenerate CODAL firmware means a student can start with \"make the LEDs do a heartbeat\" and, later in the same term, end up reading an accelerometer in C and understanding why. The hardware doesn't change; the depth does.
Safety note: the server runs a real build toolchain. Keep it sandboxed, give it access only to the project directory, and treat any agent that can write main.cpp the way you'd treat a student with sudo — supervised, scoped, and easy to roll back.This is the cheapest complete agentic stack I know of. A class set of micro:bit v2 boards is roughly $15 each; one Raspberry Pi can host the MCP server, the build, and a local model via Ollama and serve the room as a hotspot. Thirty boards and a Pi comes in under $1000 — no per-seat licences, no cloud API keys, nothing that trips a school firewall. That's a real embedded-AI lab for the cost of a single laptop.
npm install -g microbit-claude-mcp\n# REST on :3040, or wire the stdio MCP bridge into your agentPoint your agent at it, ask for a behaviour, and let it generate the C++, build the hex, and hand it back for you to flash and inspect. Small change, visible output, explicit verification — the loop I want every learner to internalise.
Teachers: if you had an agent sitting next to a class set of micro:bits, what's the first lesson you'd hand it? #microbit #edtech — I read every reply.
There's a gap between \"I trained a model\" and \"it's running on a phone in someone's hand,\" and for a lot of learners that gap is an Android build system they've never met. android-mcp (on npm as eoinedge-android-mcp) is my attempt to let an agent carry them across it.
It's an MCP bridge that wraps the host's Git, Gradle, and ADB tools so an agent can scaffold, validate, build, and deploy an Edge Impulse on-device inferencing app — the whole pipeline, headless, no Android Studio GUI required.
setup_base — pull the base app (edgeimpulse/example-android-inferencing) via a sparse Git checkoutdoctor — check the host has a working JDK and Android SDK/NDK before anything else fails confusinglygradle_tasks — list what the project can doassemble_debug — build the debug APK through the Gradle wrapperinstall_debug / adb_devices — see connected devices and push the build to oneIt listens on port 3094. One nice, very real detail: the base repo is pulled with a sparse checkout specifically to dodge Windows long-path issues — the kind of papercut that silently defeats a beginner on a school laptop and never shows up in a tutorial written on a Mac.
Because the Android build is precisely the part that isn't the lesson. The lesson is the model, the data, the inference, the thing the phone now understands. doctor exists so the agent can tell a student \"your NDK is missing\" in plain language instead of letting Gradle bury it in a stack trace. assemble_debug and install_debug turn \"forty minutes of environment yak-shaving\" into \"it's on your phone, go test it.\"
As ever: the tools here are thin wrappers over real actions, and the value is the skill that chains them — setup → doctor → assemble → install → observe. Every step produces an inspectable result, so when something breaks the student sees where, not just that the magic stopped working. That's the same human-in-the-loop principle behind all of this: support and empower, don't replace the thinking.
Safety note: this runs Gradle and ADB against your host and your connected devices. Keep it on a trusted machine, scoped to the project, and don't point install_debug at a phone you haven't unlocked for development on purpose.npm install\nnpm run setup:base\nnpm run startIt pairs naturally with the Edge Impulse MCP work: train and export with one server, then build and deploy to a real device with this one, with an agent stitching the two ends together.
If you teach mobile or edge ML, where does your class lose the most time — training, or the deploy-to-device slog? I'd like the skills here to delete whichever one it is.
The LEGO Education WeDo 2.0 app is being retired on July 31 2026. That's 54 days from when I'm writing this. It's the official programming environment for a robot kit that's in classrooms all over the world, and after that date, LEGO's position is essentially: good luck.
After 14 years teaching kids programming, electronics, and robotics, that's exactly the kind of thing that annoys me into building something. Perfectly good hardware shouldn't become e-waste because a piece of software reached end-of-life.
The result is Mindstorms Robot Creator — a browser-based IDE that covers every programmable LEGO hub that ever existed, from the 1998 RCX brick to WeDo 2.0. It's on npm as mindstorms-robot-creator, and the browser app — now at v0.6 — runs on GitHub Pages with no install required.
The core idea is profile-driven code generation. You describe your robot as a JSON port map — motor on A, motion sensor on B, that kind of thing — and the app generates correct, runnable Python for whichever target you've picked. It's not AI-generated code; it's templated generation from known hardware configurations, which means it's reliable and inspectable. (That word again. It's the whole philosophy.)
Targets covered:
The RCX support is probably the most unnecessary thing I've ever built and I have absolutely no regrets about it.
The WeDo 2.0 Smart Hub (45301) is a Nordic nRF51822: Cortex-M0 at 16 MHz, 256 KB flash, 16 KB RAM, BLE 4.0. That's a completely normal embedded target. The app might be going away, but the hardware is just a microcontroller, and there are several reasonable paths forward:
Blockly was already in the app for Robot Inventor and SPIKE Prime. WeDo 2.0 needed a completely separate block palette because the hub-module API is different: hub.port.A.motor.run_for_seconds(), hub.motion.tilt_angles(), and so on. The toolbox switches automatically when you select a WeDo 2.0 profile, and the intent system — beep hello, safe probe, drive forward, wave — generates appropriate starter blocks so nobody's staring at a blank canvas. The safe-probe intent tests each connected motor in both directions first, which saves a lot of \"why isn't my motor working\" debugging.
There's an Android build of the same thing now, with a one-tap Simple Mode that drops a child straight into a full-screen block canvas — fewer menus, bigger blocks, one Run button. That's the version I'd actually put in front of a ten-year-old, and the same kid can graduate to the full interface without changing tools or hardware.
Following on from the Edge Impulse MCP work, I added an MCP server that exposes the robot creator's code generation as tools a language model can call. Same pattern as always: tools are thin wrappers over real actions, skills are the reusable multi-step workflows. A session looks like: scan for known profiles → describe the robot → generate code for a chosen intent → optionally run it on the hub → observe → iterate. The handoff tool even generates step-by-step instructions for getting the code into the official app, including a note about the EOL date.
The custom firmware repo covers four inference approaches, and the honest comparison matters because the nRF51822 is tight:
The repo also has a Python script that takes a Keras model, quantises the weights to INT8, and exports a C++ header you can include directly — useful if you want the roll-your-own path but don't fancy doing the quantisation by hand.
If you have WeDo 2.0 kits and you're wondering what to do after July 31:
The hardware isn't going anywhere. Whether the software ecosystem follows it is a different question — and as of July 31, it's partly an open-source problem now.
If you've got LEGO kits in a store cupboard you assumed were dead, tell me which generation — I want to make sure the creator covers the ones still in classrooms.
Last week I joined a livestream roundtable at Imagine Innovators Amsterdam alongside George Grey from Foundries.io, talking about how to take Linux-based Edge AI solutions from silicon all the way through to production deployment.
George's talk covered the full arc: hardware selection, software platforms, application deployment, and lifecycle management in the CRA era. The stat that keeps coming up — over 70% of IoT and edge projects fail to reach production — isn't surprising if you've been in the space long enough. The gap between a working prototype and something robust enough to ship is where most projects quietly die.
A few things stood out from the discussion:
Most of what I build sits at the other end of this pipeline — the small, cheap, on-a-shelf hardware where people are still trying to get the prototype working at all. But the production gap George described is the same gap, just scaled up: the distance between \"it runs on my bench\" and \"it survives in the field\" is where the real engineering lives. The full recording is on the Edge Impulse YouTube channel if you missed the livestream.