mcp-server-shieldtv
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SHIELDTV_HOST | No | The Shield's IP address or hostname. Overrides the value from config.json. When the host is set in more than one place, the most specific wins: `pair --host`, then `SHIELDTV_HOST`, then `config.json`. | |
| XDG_CONFIG_HOME | No | Standard base directory, used when SHIELDTV_CONFIG_DIR is unset. Default is ~/.config. | |
| SHIELDTV_CONFIG_DIR | No | Where the certificate, key and config.json live. Defaults to $XDG_CONFIG_HOME/mcp-server-shieldtv. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_statusA | Start here. Whether the Shield is reachable, its power state, the foreground app, and volume. When it isn't reachable, stale is true: power, app and volume are the last known values (as_of says when), and error says why. It does not say what is playing; get_now_playing does (if ADB is set up). dry_run true means actions are reported, not sent. |
| get_now_playingA | Report what is playing: app, title, subtitle (artist or channel), play state, position in seconds. state is "idle" when nothing is playing. position_s is null for live TV. Needs ADB, enabled once with
|
| get_remotesA | List the Shield's Bluetooth remotes (e.g. a Harmony hub) and whether each works. state is "working", "stuck" (connected but its buttons do nothing; advice says how to fix it), "connecting" or "disconnected" (normal for a remote not in use). Needs ADB (adb-setup). |
| reboot_shieldA | Restart the Shield. Only do this when the user asks for a reboot: it stops whatever is playing. Takes about a minute: waits until the Shield is back, then checks the Bluetooth remotes, since a reboot can leave them connected but not working. If so, advice says how to fix it. Needs ADB (adb-setup). |
| list_appsA | List the app names launch_app accepts (friendly name -> the link it opens). |
| send_keyA | Press a remote-control key on the Shield, e.g. DPAD_DOWN with repeat=3 to move down three rows. |
| launch_appA | Launch an app by friendly name (see list_apps), e.g. 'netflix' or 'youtube'. Succeeds only once the app is confirmed in the foreground; otherwise the error says what the Shield did. |
| set_powerA | Wake the Shield ('on') or put it to sleep ('off'). Uses WAKEUP/SLEEP, not the POWER toggle. Succeeds only once the Shield reports the new state. Already in that state: nothing is sent. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| watch | Wake the Shield, open an app, and get to what you want to watch. |
| remotes_not_working | Check the Shield's Bluetooth remotes and say how to fix one that's connected but dead. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| apps | |
| keys |
TDQS
Scored across 8 tools
Each tool targets a distinct action/resource: input (send_key, launch_app), power (set_power), reads (get_status, get_now_playing, get_remotes, list_apps), and lifecycle (reboot_shield). The only near-overlap, get_status vs get_now_playing, is clearly delineated (device state vs playback content).
All eight tools follow a consistent snake_case verb_noun pattern (send_key, launch_app, set_power, get_status, get_now_playing, get_remotes, reboot_shield, list_apps). No mixing of conventions or vague verbs.
Eight tools is well-scoped for a media-device controller, covering input, power, status, playback, remotes, and reboot without bloat. Each tool earns its place.
Core lifecycle (power, input, launch, status, playback, reboot) is well covered, and volume/pause are reachable via send_key. Minor gaps exist for explicit volume setting or text entry, but no dead ends for typical control workflows.