Enables control of Roku TVs via the External Control Protocol (ECP), including remote button presses, app launching, device discovery, and querying device information.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Roku Control launch Netflix on the TV"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables AI assistants and agentic systems to control TVs on your local network.
Currently supports: Roku TVs via the External Control Protocol (ECP).
Based on mcp-remote-control by Aaron Goldsmith. This fork adds auto-discovery of Roku TVs via SSDP (with HTTP subnet scan fallback), fixes a connection pool exhaustion bug in the subnet scanner, and includes WSL2 networking guidance.
The Model Context Protocol is an open standard that allows AI models to securely interact with external tools and data sources. This server exposes TV controls as MCP tools, enabling LLMs like Claude to control your TV through natural language commands.
Related MCP server: Smartest-TV
This project is designed with future extensibility in mind. The Roku-specific implementation is isolated in roku_bridge.py, separating the ECP protocol details from the MCP server layer. While the current implementation is Roku-specific, the structure provides a foundation for supporting additional TV brands and control protocols in the future.
Natural Language Control: Tell your AI assistant "turn on Netflix" or "increase the volume" without touching a remote
Smart Home Integration: Integrate TV control into agentic workflows and automation systems
Accessibility: Control your TV through conversational interfaces
Development: Build custom applications that leverage AI-powered TV control
Before using this server, you need to enable external control on your Roku TV:
Enable Network Control:
Go to Settings > System > Advanced system settings
Select Control by mobile apps
Choose Network access and set to Default or Permissive
Find Your TV's IP Address (optional — auto-discovery is supported):
Go to Settings > Network > About
Note the IP address (e.g., 192.168.1.100)
Set Environment Variable (optional):
export HOST_IP=192.168.1.100 # Replace with your TV's IPIf HOST_IP is not set, the server will automatically scan the local network for Roku TVs on startup using SSDP. You can also trigger discovery at any time with the discover_tv() tool.
Python: 3.12 or higher
Network: TV and computer must be on the same local network
MCP Client: An MCP-compatible client like Claude Desktop, Claude Code, Goose or custom implementations
Remote Control: Simulate button presses (navigation, playback, volume, power)
App Launching: Launch apps by name (e.g., "Netflix", "YouTube")
App Discovery: List all available apps and their IDs
Device Info: Query device information
Auto-Discovery: Automatically find Roku TVs on the local network via SSDP — no static IP required
The package is available on PyPI.
The easiest way to use this server is via uvx, which runs the package directly from PyPI without requiring a separate install step:
uvx mcp-roku-controlAlternatively, install globally with pip:
pip install mcp-roku-controlAdd this server to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"tv-control": {
"command": "uvx",
"args": ["mcp-roku-control"],
"env": {
"HOST_IP": "192.168.1.100"
}
}
}
}Replace 192.168.1.100 with your TV's IP address.
After updating the config, restart Claude Desktop. You can then ask Claude to control your TV:
"Turn on my TV and launch Netflix"
"Increase the volume"
"What apps are available on my Roku?"
Install the server using the MCP server manager in Claude Code. See the Claude Code documentation for details.
This server uses the standard MCP protocol over stdio. See the MCP documentation for connecting local servers to your MCP client.
If you want to modify the server or contribute to development, clone the repository and install in editable mode:
git clone https://github.com/AaronGoldsmith/mcp-remote-control.git
cd mcp-remote-control
pip install -e .
# or with uv:
uv pip install -e .To use your local development version with Claude Desktop, point to the cloned directory:
{
"mcpServers": {
"tv-control": {
"command": "uv",
"args": ["--directory", "/absolute/path/to/mcp-remote-control", "run", "mcp-roku-control"],
"env": {
"HOST_IP": "192.168.1.100"
}
}
}
}Replace /absolute/path/to/mcp-remote-control with the actual path to your cloned repository.
press_key(key_name)Simulates a button press on the TV remote.
Navigation: Home, Up, Down, Left, Right, Select, Back
Playback: Play, Pause, Rev (Rewind), Fwd (FastForward)
Volume: VolumeUp, VolumeDown, VolumeMute
Power: PowerOff, PowerOn
Other: Info, InstantReplay, Search
launch_app(app_name)Launches an app by name (case-insensitive). Examples:
launch_app("Netflix")
launch_app("youtube")
launch_app("Disney+")
list_apps()Lists all available apps with their names and Roku channel IDs.
get_device_info()Retrieves device information as XML.
power_on()Powers on the TV.
discover_tv()Scans the local network for Roku TVs via SSDP and updates the active TV to the first device found. Useful when HOST_IP is not set or when the TV's IP address has changed.
The following apps are supported and can be launched by name using launch_app(). App names are case-insensitive and some apps have multiple accepted names (e.g., "Prime Video" or "Amazon Prime Video").
App Name | Channel ID | Alternative Names |
Netflix | 12 | - |
YouTube | 837 | - |
Amazon Prime Video | 13 | Prime Video |
Hulu | 2285 | - |
Disney+ | 291097 | Disney Plus |
HBO Max | 61322 | - |
Apple TV+ | 551012 | Apple TV |
Peacock | 593099 | - |
Paramount Plus | 31440 | Paramount+ |
ESPN | 34376 | - |
Tubi | 41468 | - |
Sling TV | 46041 | - |
STARZ | 65067 | - |
CBS | 619667 | - |
CNN | 65978 | - |
Pluto TV | 74519 | - |
SHOWTIME | 8838 | - |
Use list_apps() to see the complete list programmatically.
Once connected to an MCP client, you can use natural language to control your TV:
User: "Turn on my TV and launch Netflix"
Assistant: *uses power_on() and launch_app("Netflix")*
User: "Show me what apps are available"
Assistant: *uses list_apps() to display all installed apps*
User: "Navigate down 3 times and select"
Assistant: *uses press_key("Down") three times, then press_key("Select")*
User: "Pause what's playing"
Assistant: *uses press_key("Pause")*Model Context Protocol Documentation - Official MCP docs and specification
MCP GitHub Repository - Source code and examples
MCP Servers Registry - Collection of community MCP servers
Building MCP Servers Guide - Learn to build your own MCP servers
Roku ECP Documentation - Official External Control Protocol documentation
Roku Developer Portal - Additional Roku development resources
Connection Failed: Ensure your TV and computer are on the same network and the TV's IP address is correct
Control Not Working: Verify that "Control by mobile apps" is enabled in your TV settings
App Not Launching: Check that the app is installed on your TV using list_apps()
Environment Variable: HOST_IP is optional — if omitted, auto-discovery runs at startup. Set it explicitly if discovery is slow or unreliable on your network.
SSDP discovery requires an inbound Windows Firewall rule to allow UDP responses from your local network to reach the WSL2 process. Run the following in an elevated PowerShell (replace the subnet if your home network differs):
New-NetFirewallRule -DisplayName "Roku SSDP WSL2" -Direction Inbound -Protocol UDP -RemoteAddress 192.168.1.0/24 -Action AllowWithout this rule, SSDP M-SEARCH responses are silently blocked by Windows Firewall. The server will fall back to an HTTP subnet scan, which works but is slower (~5–10 s vs. < 1 s for SSDP).
MIT
Scans the local network for Roku TVs via SSDP and returns the discovered devices.
Also updates the active TV to the first device found. Useful when HOST_IP is not configured or when the TV's IP address may have changed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it updates the active TV to the first found device, which is a notable side effect. With no annotations, the description carries the full burden and does so well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded action and side effect, then usage scenario. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, side effect, and usage. Output schema exists to detail return values. Could mention potential delays from network scanning, but not necessary for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description adds no param info beyond the empty schema. Baseline for 0 params is 4, and the schema coverage is trivially 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scans for Roku TVs via SSDP and returns discovered devices, with a distinct side effect of updating the active TV. This differentiates it from sibling tools like get_device_info or launch_app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies it is useful when HOST_IP is not configured or IP may have changed. No direct exclusion of when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves basic device information (model, software version, etc.) as XML.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the output format (XML) but does not mention that the operation is read-only, side-effect-free, or idempotent. Lacks depth for a tool with zero annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the purpose and format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so the description need not explain return values. The description covers the core purpose and format. However, lacking usage guidelines or behavioral notes makes it slightly incomplete for a completely annotation-free tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is 100%. Per the rules, baseline is 4. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves basic device information (model, software version) as XML. It distinguishes from sibling tools like 'discover_tv' or 'launch_app' which have different purposes, but 'etc.' slightly reduces specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. While siblings are functionally distinct, the description does not provide any context on prerequisites or when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launches an application on the TV using its name.
Args: app_name: The name of the app to launch (e.g., Netflix, YouTube, Hulu). Case-insensitive. Use list_apps() to see available apps.
| Name | Required | Description | Default |
|---|---|---|---|
| app_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full responsibility for behavioral disclosure. It notes case-insensitivity but does not mention error handling (e.g., if app not found), return values, or side effects (e.g., if TV powers on automatically). This leaves gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three brief sentences), uses a clear 'Args:' structure, and contains no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (not shown but present), the description need not detail return values. It sufficiently explains the app_name parameter and references list_apps. Lacks mention of prerequisites (e.g., TV power state) but is otherwise complete for a simple launch action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter app_name is enriched with examples (Netflix, YouTube), case-insensitivity note, and a reference to list_apps. Since schema description coverage is 0%, the description provides all necessary semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it launches an application on the TV by name, which is specific and distinguishes from sibling tools like list_apps (listing apps) and press_key (key input).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using list_apps() to see available apps, providing useful prerequisite guidance. However, it does not explicitly mention when to use this tool versus alternatives or conditions like whether the TV must be on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all available apps and their corresponding Roku channel IDs.
Returns a formatted list of app names and their IDs that can be used with launch_app().
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions what the tool returns (a formatted list). It does not disclose any additional behavioral traits such as caching, dependencies, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description adequately explains what is returned and its utility. It is missing potential limitations but is sufficient for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4. The description adds no parameter information, but this is acceptable since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'lists' and the resource 'all available apps and their corresponding Roku channel IDs', and distinguishes it from sibling tool 'launch_app' by explaining how the output can be used with that function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining app IDs to use with launch_app(), but does not explicitly state when to use this tool versus alternatives like discover_tv or get_device_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Powers on the TV.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the intended behavior (powers on the TV) but does not disclose any additional behavioral traits such as potential delays, error scenarios, or side effects. Since no annotations are provided, the description carries the full burden, and while the core action is clear, more detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly communicates the tool's purpose with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (zero parameters, straightforward action) and the presence of an output schema, the description is minimally adequate. However, it omits useful context such as prerequisites (TV off), expected response, or potential side effects. For a trivial action, this may be acceptable, but more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the input schema is fully covered (100%). The description does not need to add parameter information. With zero parameters, a baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (power on) and the resource (the TV). It is distinct from sibling tools like discover_tv, get_device_info, launch_app, list_apps, and press_key, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives. For example, it does not mention that the TV should be off before calling, or suggest checking the TV state first with get_device_info. No exclusion criteria or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simulates a single button press on the TV remote.
Args: key_name: The name of the key to press (e.g., Home, Select, VolumeUp). Common keys are Home, Back, Select, Up, Down, Left, Right. Special keys are: PowerOn, PowerOff, VolumeUp, VolumeDown, VolumeMute
| Name | Required | Description | Default |
|---|---|---|---|
| key_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only states it simulates a press, lacking details on prerequisites (e.g., active TV connection), side effects, or error conditions. Minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise paragraph with clear structure (description, Args list). Every sentence adds value. Minor improvement could be more structured formatting for AI parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the core action adequately. Missing return value description despite output schema existing, and no mention of prerequisites like device connection. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds extensive meaning: lists examples, common keys, and special keys. This compensates well, though could include case sensitivity or exhaustive list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it simulates a single button press on the TV remote, with specific verb and resource. It distinguishes from sibling tools like launch_app and power_on by focusing on key presses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides examples of common and special keys, giving clear context for use. However, it does not explicitly exclude alternatives like power_on for power keys, but the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1discover_tvget_device_infolaunch_applist_appspower_onpress_keyEach tool has a clear and distinct purpose: discovering TVs, getting device info, launching apps, listing apps, powering on, and simulating key presses. No overlap in functionality.
All tool names follow a consistent snake_case verb_noun pattern (e.g., discover_tv, list_apps, press_key), making them predictable and easy to distinguish.
Six tools is an appropriate scope for a remote control server, covering discovery, information retrieval, app management, power control, and key input without being excessive.
The tool set covers most core remote control actions, including power on, key presses (volume, navigation, etc.), and app launching. A minor gap is the lack of an explicit power off tool, though press_key can send PowerOff.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Control your Tesla from your AI assistant - climate, charging, access, and security.
Turns a phone into a camera+Bluetooth remote so AI assistants can see and control any PC.
Manage digital signage screens, playlists and media from your AI assistant.
Control Android TV from any AI. 38 MCP tools: playback, recap, recommend, smart-home, schedules.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/charlysotelo/mcp-roku-control'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
