What can you do with this server?

The mcp-gtv server lets you control paired Google TV devices from any MCP-compatible client (e.g. Claude Desktop, Cursor), with no additional API keys required — just devices pre-paired via the @kud/gtv-cli tool. * List paired devices: View all paired Google TV devices, with the currently active one marked. * Switch active device: Change which TV subsequent commands target, by IP address or device name. * Send remote key presses: Simulate any remote button — navigation (up/down/left/right/select), media (play/stop/next/prev/fwd/rwd), volume (vol-up/vol-down/mute), power (power/sleep/wakeup), and more (home, back, menu, search, input, settings, guide, info, etc.). * Type text via IME: Input arbitrary text directly into a focused field (e.g. search queries), bypassing keycode-by-keycode mapping. * Launch apps: Open apps by catalog name (e.g. netflix, youtube, spotify, disney, plex) or by a raw deep-link URI. * Read TV state: After executing a command, receive feedback on the TV's power status, foreground app, and volume level.

Which integrations are available for this server?

Controls Google TV devices: send remote keys, type text via IME, list and switch devices, and launch apps. Launches the Netflix app on Google TV. Launches the Plex app on Google TV. Launches the Prime Video app on Google TV. Launches the Spotify app on Google TV. Launches the Twitch app on Google TV. Launches the YouTube app on Google TV.

How do I use mcp-gtv?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-gtv Turn up the volume on my 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.

mcp-gtv

by kud

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

TypeScript Node.js npm Experimental MIT

MCP server for Google TV — control paired devices (keys, text, app launch) via @kud/gtv.

Features • Quick Start • MCP Client Setup • Tools Reference • Development

Proof of concept — experimental and unfinished. This package is not yet published to npm. The API, tool names, and behaviour may change or break at any time. Run it from source (see Development). Do not use in production.

@kud/mcp-gtv exposes Google TV control to any MCP client, letting an assistant open apps, control playback, type into search fields, and read back what's currently on the TV.

🌟 Features

🔌 Zero credentials — reads paired devices from ~/.config/gtv/config.json; no API key, no token, no extra setup
📺 Device switching — list all paired TVs and switch the active target at any time during a session
🎮 Full remote control — send any key from navigation and media to volume, power, and input
⌨️ IME text input — type arbitrary text into the focused field directly, without keycode mapping
🚀 App launcher — launch Netflix, YouTube, Prime Video, Spotify, and more by name, or pass any raw deep-link URI
📡 State feedback — every control tool returns the TV's resulting state (power, volume, foreground app) so the model can confirm its action landed
🤖 Broad MCP client support — stdio transport works with Claude Desktop, Claude Code, Cursor, and any MCP-compatible client

Related MCP server: AndroidTVMCP

🚀 Quick Start

1. Pair your TV first

Pairing is handled by @kud/gtv-cli, not this server. If you have not paired a device yet:

npx @kud/gtv-cli pair

Follow the PIN prompt on the TV. The paired device is written to ~/.config/gtv/config.json — the shared config store that mcp-gtv reads automatically. You only need to do this once per device.

2. Run the server from source

The package is not yet on npm. Clone the repo and run with tsx:

git clone https://github.com/kud/mcp-gtv.git
cd mcp-gtv
npm install
npm run dev

3. Ask naturally

Once an MCP client has the server connected:

"What's playing on the TV right now?" "Open Netflix" "Turn up the volume" "Go back to the home screen" "Type 'Blade Runner' into the search field"

What it's good at

This server works well for discrete, confirmable actions: opening apps, controlling playback, adjusting volume, typing into search, and checking what's currently on screen. It is not suited to navigating menus or lists inside an app — see Known Limitations.

🔧 MCP Client Setup

The server uses stdio transport and requires no environment variables.

Not yet on npm. The npx @kud/mcp-gtv form shown below will not work until the first publish. For now, use the local dev config instead.

Local development (current)

Add to .mcp.json in your project root, pointing at your local clone:

{
  "mcpServers": {
    "mcp-gtv": {
      "command": "npx",
      "args": ["tsx", "/path/to/mcp-gtv/src/index.ts"]
    }
  }
}

The repo also ships a .mcp.json at the root — open the repo in Claude Code and it will be picked up automatically.

Claude Desktop / Claude Code (once published)

{
  "mcpServers": {
    "mcp-gtv": {
      "command": "npx",
      "args": ["-y", "@kud/mcp-gtv"]
    }
  }
}

Claude Desktop — edit ~/Library/Application Support/Claude/claude_desktop_config.json.

Claude Code — add to .mcp.json in your project root, or to ~/.claude/mcp.json for global availability.

Cursor / other MCP clients

Use the same npx -y @kud/mcp-gtv command with stdio transport once published. Consult your client's documentation for the exact config location.

🛠 Tools Reference

Every control tool returns the TV's resulting state (connected, powered, foreground app, volume) so the model can confirm its action landed.

Tool	Description	Arguments
`gtv_list_devices`	List all paired devices, marking the current one	—
`gtv_set_device`	Switch the active device by host (IP) or name	`device: string`
`gtv_get_state`	Read live state: connected, powered, foreground app (package + friendly name), volume	—
`gtv_send_key`	Send a remote key press; power and volume keys wait for the state echo	`key: string`
`gtv_type_text`	Type text into the focused field via IME	`text: string`
`gtv_launch_app`	Launch an app by catalog name/id or deep-link URI; waits for and returns the foreground app with a `confirmed` flag	`app: string`

Valid keys for `gtv_send_key`

home  back  power  up  down  left  right  select
play  stop  next   prev  fwd  rwd
vol-up  vol-down  mute
menu  search  sleep  wakeup  input  enter
channel-up  channel-down  info  guide  settings

App catalogue for `gtv_launch_app`

ID	App
`netflix`	Netflix
`youtube`	YouTube
`primevideo`	Prime Video
`plex`	Plex
`putio`	Put.io
`arte`	Arte
`disney`	Disney+
`spotify`	Spotify
`twitch`	Twitch
`max`	Max

You can also pass any raw deep-link URI directly (e.g. intent://... or market://launch?id=com.example.app).

⚠️ Known Limitations

No screen awareness. The Android TV Remote protocol only streams power state, volume, and foreground app package — never screen contents, focus position, or menu structure. The server can launch apps, control playback, type into search, and confirm those actions landed. It cannot see the screen, so navigating menus, folders, or lists inside an app is not reliably possible. Deep in-app navigation would require an ADB or computer-vision channel; that is deliberately out of scope.
Store-mediated app launching. App launch uses market://launch?id=<package>, which the Play Store may auto-launch OR simply display as a store listing (showing an "Open" button) even when the app is installed. Reliable direct launch is not available over the remote protocol. When the store page opens instead, send select to open the app.
Current device only. All tools act on the device selected by gtv_set_device (or the default from the config). Interactive pairing over MCP is not implemented — pair first with npx @kud/gtv-cli pair.
First-call latency. The first tool call in a session opens a TLS connection and waits for the TV's telemetry burst to settle (~350 ms quiet, capped at 2 s). Subsequent calls reuse the warm session and are near-instant.

🔧 Development

Project layout

mcp-gtv/
├── src/
│   └── index.ts        # MCP server — session management, all tool handlers
├── test/
│   └── tools.test.ts   # Unit tests (Node built-in test runner)
├── dist/               # Compiled output (tsup, gitignored)
├── .mcp.json           # Local MCP client config for dev (auto-loaded by Claude Code)
├── TESTING.md          # Manual test plan — run against a real TV before publishing
└── tsup.config.ts

Scripts

Script	Purpose
`npm run dev`	Run source directly with `tsx`
`npm run build`	Compile to `dist/` via tsup
`npm run build:watch`	Watch mode
`npm run test`	Run test suite (Node built-in runner)
`npm run typecheck`	TypeScript type check only
`npm run inspect`	Open MCP Inspector for interactive tool testing

Clone and run

git clone https://github.com/kud/mcp-gtv.git
cd mcp-gtv
npm install
npm run dev

Use npm run inspect to open the MCP Inspector and exercise all tools interactively without a full MCP client.

Testing

A manual test plan that covers every tool against a real TV lives in TESTING.md. Run through it before any publish.

Releasing

Releases are tag-driven via GitHub Actions with OIDC Trusted Publishers — no manual npm publish needed. The first publish has not happened yet; once the initial OTP bootstrap is done, subsequent releases will follow the tag workflow:

git tag v0.2.0
git push origin v0.2.0

🏗 Tech Stack

Package	Role
`@kud/gtv`	Google TV domain library — device store, key codes, app catalogue, remote connection
`@modelcontextprotocol/sdk`	MCP server primitives (`McpServer`, `StdioServerTransport`)
`zod`	Tool input schema validation
`tsup`	ESM bundler / compiler
`tsx`	TypeScript execution for dev and tests

Ecosystem

@kud/androidtv-remote   ← low-level pairing & remote protocol
       ↑
  @kud/gtv              ← domain library (devices, keys, apps)
       ↑
  ┌────┴────┐
  │         │
mcp-gtv   gtv-cli       ← MCP surface / terminal surface

This server is the MCP client surface of the ecosystem. @kud/gtv-cli is the interactive terminal counterpart — and the tool you use to pair devices before this server can control them.

MIT © kud — Made with ❤️

Available Tools

5 tools

gtv_launch_appA

Launch an app on the current device by catalog name/id (e.g. netflix, youtube) or a raw deep-link URI.

ParametersJSON Schema

Name	Required	Description	Default
`app`	Yes	App catalog name/id or a deep-link URI

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must compensate. It minimally describes the input format but omits behaviors like error handling (e.g., what if app not found?), permissions, or side effects (e.g., does it change focus?). For an action tool, this lack of behavioral detail impairs correct invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with clear structure: action, target, input format. No unnecessary words, front-loads the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple interface (one required parameter, no output schema), the description covers the input and action adequately. However, it lacks details on expected outcomes, error states, or device requirements, leaving gaps in completeness for an agent to handle edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, baseline is 3. The tool description adds examples (netflix, youtube) and clarifies the dual nature (catalog name vs. deep-link URI), which adds meaningful context beyond the schema field description. However, it does not introduce new parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: 'Launch an app on the current device'. It specifies input types with examples (catalog name/id like netflix, or deep-link URI), and the purpose is distinct from sibling tools which handle device listing, key sending, device setting, and text typing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this vs siblings or prerequisites (e.g., device must be set). The implication that it works on the 'current device' hints at a precondition, but it's not spelled out. Sibling names suggest context, but no exclusions or alternatives are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gtv_list_devicesA

List Google TV devices already paired via the gtv CLI, marking the current one.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description clearly states it lists devices and marks the current one, implying a read-only operation. No hidden side effects mentioned; however, no disclosure of potential timeouts or network requirements, but suitable for a simple list.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is front-loaded and contains no extraneous information. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, no output schema, and a simple operation, the description fully informs the agent. No additional information is necessary for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline is 4. The description adds meaning beyond schema by explaining the tool's function (list + mark current device), which is helpful for an agent even with zero params.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs ('List') and resource ('Google TV devices already paired via the gtv CLI'), and distinguishes from siblings (other gtv tools like launch, send key, set device, type text). It also adds a unique behavior: marking the current device.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use versus alternatives, but for a zero-parameter listing tool, the context of sibling tools (e.g., gtv_set_device) implies this is for viewing paired devices before selecting one. The minimal guidance is adequate given simplicity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gtv_send_keyA

Send a single remote key press to the current device (navigation, media, volume, power…).

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes	Remote key name, e.g. home, up, play

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It mentions 'current device' but does not disclose error states, side effects, or whether the press is reliably delivered. Minimal behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no redundant words, front-loads the core action. Every word contributes to clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 enum param, no output schema), the description is adequate but lacks information about return value, error handling, or device state requirements. Could be more self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with enum values and a brief description. The description adds value by grouping keys into categories (navigation, media, volume, power), enriching the meaning beyond the raw list.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'send' and resource 'remote key press', specifying the scope to the current device and listing key categories (navigation, media, volume, power). It distinguishes from sibling tools like gtv_type_text and gtv_launch_app.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (when a remote key press is needed) but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gtv_set_deviceA

Select which paired device subsequent commands target, by host (e.g. 192.168.1.42) or name.

ParametersJSON Schema

Name	Required	Description	Default
`device`	Yes	Device host (IP) or name

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Does not disclose behavioral traits beyond the basic selection action, such as whether it overwrites a previous device, requires prior pairing, or echoes any confirmation. Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no superfluous words. Clearly front-loaded with the action and resource. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple context-setting tool with one parameter and no output schema, the description is largely complete. It could mention that the device must be paired and that subsequent commands will use this selection, but overall it suffices for basic usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter, so baseline is 3. Description adds an example ('e.g. 192.168.1.42') but largely restates the schema description ('Device host (IP) or name'). No significant additional meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action (select), resource (paired device), and method (by host or name). Distinguishes from sibling tools like gtv_list_devices (listing) and gtv_send_key (sending keys) by specifying that it sets a target for subsequent commands.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies when to use (before other commands that need a target), but lacks explicit guidance on when not to use or alternatives. For example, if a command already accepts a device parameter, this tool might be unnecessary, but no such context is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gtv_type_textA

Type arbitrary text into the focused field on the current device via IME (no keycode mapping).

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Text to type into the focused field

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the IME method and lack of keycode mapping, but does not specify behavior when no field is focused, supported character sets, or potential side effects. It adds moderate behavioral context but lacks completeness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the essential information (action, target, method). Every word earns its place with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema) and lack of annotations, the description adequately covers the tool's purpose and behavior. It does not mention error handling or fallbacks, but for a straightforward text input tool, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage for the single 'text' parameter, already describing it as 'Text to type into the focused field'. The description adds no extra parameter-specific meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Type arbitrary text'), the target ('into the focused field'), and the method ('via IME'). It also distinguishes from sibling tool 'gtv_send_key' by noting 'no keycode mapping', making the purpose precise and unique.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (for direct text input) versus alternatives like gtv_send_key (for key presses). It does not explicitly state exclusions or name the sibling, but the context is clear enough for an agent to differentiate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Jun 21, 2026
- First observedgtv_launch_app
- First observedgtv_list_devices
- First observedgtv_send_key
- First observedgtv_set_device
- First observedgtv_type_text

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Scored 2026-06-21 18:55 across 5 tools

Disambiguation5/5

Each tool targets a distinct operation: device selection, device listing, app launching, key sending, and text typing. There is no overlap in their purposes.

Naming Consistency5/5

All tools follow a consistent 'gtv_verb_noun' pattern (e.g., gtv_launch_app, gtv_list_devices), making the naming predictable and easy to understand.

Tool Count5/5

With 5 tools, the server covers the essential remote control operations for Google TV devices without being overly narrow or bloated.

Completeness4/5

The tool set covers device management, navigation, text input, and app launching. A minor gap might be the lack of a tool to retrieve device info or current state, but the core remote control functionality is well-covered.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

KodyOAuth
io.github.kentcdodds
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
Developer Tools Code Execution Command Line
2617
mcp-serpOAuth
io.github.AceDataCloud
MCP server for Google search results via SERP API
Search Browser Automation Web Scraping
21
Speechtotext Mcp
io.github.varvararatta
MCP server for Speech-to-Text
Speech Processing AI & Machine Learning
2
Texttospeech Mcp C
io.github.varvararatta
MCP server for Text-to-Speech
Text-to-Speech Speech Processing Audio Processing
2

Related MCP Servers

mcp-gsuite
Calendar Management Communication App Automation
MarkusPfundstein
A
license
Not graded
quality
F
maintenance
MCP server to interact with Google produts.
Updated a year ago (2025-04-14 10:41 UTC)
490
MIT
AndroidTVMCP
Agent Orchestration Home Automation & IoT OS Automation
pigeek
A
license
Not graded
quality
C
maintenance
A Model Context Protocol server that enables AI assistants to control Android TV devices, providing remote control functionality like navigation, playback control, app management, and device status monitoring.
Updated 6 months ago (2026-03-04 03:11 UTC)
9
MIT
MCP Remote Control
Home Automation & IoT App Automation Entertainment & Media
AaronGoldsmith
F
license
A
quality
D
maintenance
An MCP server that enables AI assistants to control TVs on a local network through natural language commands. It currently supports Roku devices, allowing users to launch apps, manage playback, and navigate menus.
Updated 9 months ago (2025-12-14 18:53 UTC)
5
-
remote-control-tv
Home Automation & IoT Entertainment & Media
Hustawek
A
license
A
quality
D
maintenance
An MCP server that lets AI agents control Android TVs via ADB, including searching and playing content across streaming services, managing power and volume, and sending remote control commands.
Updated 5 months ago (2026-03-29 13:50 UTC)
6
12
3
MIT

🌟 Features

🚀 Quick Start

1. Pair your TV first

2. Run the server from source

3. Ask naturally

What it's good at

🔧 MCP Client Setup

Local development (current)

Claude Desktop / Claude Code (once published)

Cursor / other MCP clients

🛠 Tools Reference

Valid keys for gtv_send_key

App catalogue for gtv_launch_app

⚠️ Known Limitations

🔧 Development

Project layout

Scripts

Clone and run

Testing

Releasing

🏗 Tech Stack

Ecosystem

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Valid keys for `gtv_send_key`

App catalogue for `gtv_launch_app`