The Soup I Was In
If you do any serious Roku development, you know the friction. My day-to-day work involves calling functions deep in the player library, chaining their outputs, and validating results across many different test cases.
Every single change meant the same ritual: rework the code, bundle the channel, sideload the zip onto the Roku device, navigate through the app manually to the right state, run the workflow, check the output, repeat. Fifteen to twenty steps. Multiple times a day. Different data inputs each time.
It was the kind of repetitive work that makes you feel like you are the automation, not writing it.
The Idea: RALE as a Remote Control for My App
Roku's RALE (Roku Advanced Layout Editor) ships with a TrackerTask that provides a hierarchical view of the node tree in a RokuSceneGraph app. It also lets developers or designers dynamically lay out the visual aspects of an app for quick prototyping and design purposes.
I saw it differently. What if I extended TrackerTask with two custom functions — one to expose a list of functions from the App's Scene, and another to actually execute those functions from outside the app?
That would mean I could call my player's functions directly, pass in test parameters, get results back, and chain everything together — without touching the remote, without navigating the UI, sideloading the channel when there are actual code changes.
The catch: RALE communicates over WebSocket, not a simple HTTP endpoint you can hit from Postman. So I wrote a Python script.
The Python Script That Kept Growing
That first script was just enough to establish the WebSocket handshake and call a function. When it worked, I was genuinely elated. It felt like I had cracked open my own app and given myself a direct line into it.
Then I kept extending it. ECP queries. Sideloading the Apps. Taking screenshots. Pressing keys programmatically. Each new capability meant one less manual step in my workflow.
What started as a targeted hack for testing my player functions had turned into a fairly complete Python toolkit for Roku development. It solved my problem — but it was a collection of scripts, not something I could hand to a colleague.
Giving the Scripts a Face
I believed other Roku developers and QA engineers were in the same soup. The Roku ecosystem has always been a bit thin on developer tooling compared to other platforms. I had benefited enormously from the Roku community Slack, from colleagues at Paramount who helped me grow in streaming and Roku development, and from colleagues at Comcast who first brought me into the Roku world. I wanted to give something back.
So I decided to build a proper UI.
A web app was the first instinct — but browsers block direct HTTP calls to local network devices, and Roku's ECP runs on the device's local IP. Electron was the right answer: it runs as a Node.js process, which means no sandboxing, no network restrictions, and cross-platform support out of the box.
I started by building roku-dev-studio-api — a proper package that encapsulates all the core Roku operations: device discovery, ECP queries, sideloading, keypresses, text input, screenshots, dev auth. A clean API layer first, so the UI would just be a consumer of something already solid.
Action Scripts: The Full Circle
Of all the features I built, Action Scripts surprised me the most — both in how useful it became and in what it meant to me personally.
The idea is simple: a no-code way to build automation workflows inside Roku Dev Studio. Heavily inspired by GitHub Actions. In the Builder, you compose a script by selecting actions one at a time — the JSON builds up alongside as you go. In the Executor, you run it and see results inline.
A QA engineer testing a video playback scenario has two paths. If they don't have access to the channel internals, they can chain keypresses to navigate the app to the right asset and play it. If they do have access — if the channel has TrackerTask wired up — they can use App Connector to pass playback parameters directly to the player function and skip the UI navigation entirely.
HUD metrics, registry reads, screenshots, ECP queries — all composable, all in one script, no code required.
When I finished building Action Scripts, I sat back and realised: I had started this whole journey writing Python scripts to automate repetitive Roku workflows. And Action Scripts is exactly that same idea, now built into the tool, accessible to anyone. It felt like a full loop.
The MCP Server: AI Can Use the Tool Too
Toward the end of building Roku Dev Studio, I leaned heavily on AI tools to help me develop it. By the time I was building Action Scripts, the AI had enough context on the whole system that it could help in genuinely useful ways.
That gave me an idea. If AI helped me build this tool, could AI also use this tool?
That is the MCP server. Any AI agent running in a developer's IDE — Cursor, VS Code with Copilot, Claude Desktop — can connect to Roku Dev Studio and get direct access to the device. It can press keys, launch apps, query ECP endpoints, call App Connector functions, run RALE commands, take screenshots. Or it can author an Action Script, send it to the Builder for the developer to review, and let the human decide when to run it.
The idea is that a Roku developer using an AI coding agent no longer has to context-switch to test something on the device. The agent can do it for them, or at least set it up for review.
What Else It Does
The blog so far has covered the core story — App Connector, Action Scripts, and the MCP server. But Roku Dev Studio has grown into a fairly complete toolbox. Here is what else is in there:
BrightScript Fiddle — A Monaco-based scratch editor with live brighterscript linting. Write a BrightScript snippet, hit Run, and the tool wraps it into a minimal SceneGraph channel, sideloads it onto your selected device, and streams the debug console output directly into the window. No manual bundling, no zip, no browser tab. When you close the window it cleans up the channel from the device automatically.
Remote Control — A full on-screen remote with D-pad, media controls, and an optional keyboard mode so your arrow keys and Enter work as the remote while you are focused on the app.
Device Performance Charts — Live CPU, memory, and object count charts for any sideloaded dev channel running in the foreground. These can also be captured as chart cards inside Action Script results and exported to PDF — useful for regression testing across builds.
Device Queries — A dedicated tab for ECP queries: device info, active app, media player state, installed apps, SceneGraph nodes, SG rendezvous events, firmware beacons, plugin info, memory usage, and custom endpoints. All in one place without needing to curl by hand.
Telnet Console — Direct access to the BrightScript debug console on port 8085 and system commands on port 8080, streamed in real-time. Includes log export to file and a Log File Viewer for reviewing saved logs from a previous session or from a teammate.
App Launcher — Browse all installed apps on the device with icons, launch by app ID, deep link into specific content, and switch HDMI inputs on TV devices.
rds CLI — All of the above is also available headless from the terminal via the rds command: rds discover, rds keypress, rds sideload, rds screenshot, rds script run, rds rale repl, and more. Useful for CI pipelines or scripting without opening the desktop app.
Internet Relay — A separate roku-dev-studio-remote-server package you can run anywhere to bridge the app to Roku devices on a remote network. Every feature — remote control, sideloading, console, RALE — works through the relay, not just local devices.
Secret Screens — One-click presets for Roku's hidden developer screens (Developer Settings, Wi-Fi info, Channel Info, Reboot variants) accessible from the Remote tab without memorising the keypress sequences.
Everything is cross-platform: macOS, Windows, and Linux all have installers.
What I Want From You
Roku Dev Studio is open source, published under the Paramount Engineering GitHub organisation, and MIT licensed.
I did not build this to check a box. I built it because I was frustrated, because I believed others shared that frustration, and because I felt the Roku ecosystem deserved better tooling. The communities and people who helped me learn Roku development gave me a lot — this is my attempt to return some of that.
If you try it and find a bug, open an issue. If you have a workflow that it does not support yet, ask for a feature. If something in the codebase could be better, open a pull request. The goal is to make Roku development easier, smoother and faster — and I cannot get there alone.
Top comments (1)
As part of a new process at our org we are being asked, as QA, to demo our features to the wider QA group as a type of knowledge transfer. I didn't really want to do it all manually so I started looking for a way to leverage the parsing power of an LLM to help me capture sessions, analyze them and generate a series of demo slides explaining it all.
Since I work in the same org as @hdonapati I already knew and used his roku dev studio tool and remembered it had MCP support. I knew I would also need the proxy traffic logs to analyze the API. Luckily someone has recently released something that did exactly what I needed github.com/heizaheiza/Charles-mcp. Combining these two tools made it very easy to do what I originally wanted.
As I started playing around with this environment/workflow I started asking myself what if I trained the agent on all this data and gave it some context about how to map it to my own knowledge of how the app works. I had a real happy moment then because all sorts of possibilities started popping up in my head.
I have been experimenting by capturing layers of context in the form of data, that include proxy/api logs, key presses, telnet, scene graph dump. I use this to create an inventory of our app's various states and screens. I then map this to another layer of human generated context (test cases, requirements documentation) that takes the form of prompt rules and glossary terms. I then go through a manual process/conversation with the agent to ensure they map to one another to fit my expectations and to generate agent rules that address bugs in the design as they appear, a type of interactive debugging.
What I'm hoping to get after doing all this is an interactive, comprehensive and contextual knowledge base of how the app works with an agent that can answer questions, generate documentation (test cases, bug reports, logs, analysis) as new features are introduced.
For now I have what I originally set out to do. I can capture session data, generate demo slides, analysis, both quickly and neatly. I really think there are more possibilities here for anyone who want's to try and experiment with these tools, specifically in the area of automation. The best part is how easy it was to set up. An agent (Cursor in my case), Roku dev studio, and charles mcp.
Thanks to @hdonapati for all his work. I highly recommend roku dev studio to anyone who works with these devices.