This server acts as an MCP interface to control Stremio on Android TV, search for content via TMDB, and manage a Stremio library.
Search for movies/TV shows: Query TMDB by title, optionally filtering by type (movie, TV, or auto-detect) and year. Returns IMDb IDs for matched titles.
Play content on Android TV: Open a movie or specific TV episode in Stremio using a title (looked up via TMDB or your library) or directly by IMDb ID. Supports season and episode targeting for series.
Manage your Stremio library: List all items, view continue-watching items, search by title, check if a specific item exists, or add/remove items by IMDb ID and content type.
Control the Android TV via ADB:
Volume: increase, decrease, mute, or set to a specific level
Playback: play, pause, toggle, stop, skip next/previous, fast-forward, or rewind
Navigation: move up/down/left/right, select, back, or home
Power: wake, sleep, toggle, or check status
Check playback status: Retrieve real-time info including the app, content title, playback state (playing, paused, stalled, stopped), current position, and total duration.
A Python Model Context Protocol (MCP) server for searching TMDB, opening Stremio content on Android TV, controlling playback over ADB, and optionally accessing your Stremio library.
This server can control a physical Android TV and, whenSTREMIO_AUTH_KEY is configured, add or remove items from your Stremio library. ADB grants powerful device access. Review tool requests, keep credentials private, and disable Wireless Debugging when you are not using it.
Searches TMDB for movies and TV shows and returns IMDb IDs.
Opens a movie or a specific series episode in Stremio on Android TV.
Sends navigation, playback, volume, and power commands through native ADB.
Reads device-dependent playback title, state, position, and duration data.
Optionally lists, searches, adds, and removes Stremio library items.
Related MCP server: moviefinder-mcp
Android TV with Stremio installed and configured with working addons
For modern Wireless Debugging on TV: Android TV / Google TV running Android 13 (API 33) or higher, per Google's wireless adb requirements
Android SDK Platform Tools (adb) — install a current release and keep it updated; use at least the wireless-debugging era of Platform Tools (30.0.0+, when adb pair landed). Prefer the latest stable from the Platform Tools page for mDNS and TLS fixes
A free TMDB API key for title search
Optional: a Stremio auth key for library access
Run the latest published release without cloning the repository:
uvx stremio-mcp-serverTo run the current release explicitly:
uvx --from stremio-mcp-server==0.2.0 stremio-mcp-serverThis project is published on PyPI asstremio-mcp-server. A separate,
unrelated project is published as stremio-mcp; installing that name does not
install this server. The stremio-mcp console script below is provided by the
stremio-mcp-server distribution.
Use a source checkout for development or local modifications:
git clone https://github.com/netixc/stremio-mcp.git
cd stremio-mcp
uv sync --locked
cp .env.example .envEdit .env with your TV endpoint and API keys. The file is ignored by Git; never commit it.
TMDB_API_KEY=your_tmdb_api_key
ANDROID_TV_HOST=192.168.1.100
ANDROID_TV_PORT=37139
STREMIO_AUTH_KEY=
# ADB_PATH=/absolute/path/to/adbThis server talks to the TV through the native Platform Tools adb client, not a pure-Python ADB library. That is intentional: modern Wireless Debugging negotiates TLS (STLS) and this project needs a full shell for intents, key events, and media-session diagnostics. Pure-Python clients that only speak legacy ADB-over-TCP do not cover that path.
On the TV, enable Developer options and Wireless debugging. Menu names vary by manufacturer. Official wireless debugging for TV requires Android 13+; see Google's Connect to a device over Wi-Fi guide.
Modern Wireless Debugging displays separate pairing and connection ports (often ephemeral). Pair once, then connect with the current connection port:
adb pair TV_IP:PAIRING_PORT
# Enter the temporary pairing code shown on the TV.
adb connect TV_IP:CONNECTION_PORT
adb devices -lSet ANDROID_TV_PORT to the connection port, not the temporary pairing port. The device must appear as device, not offline or unauthorized. Wireless Debugging ports may change after a reboot or after debugging is toggled. On newer Platform Tools and Android versions, a previously paired device may also reconnect via mDNS when it returns to a trusted network; still configure the explicit connection port when the UI shows one.
Legacy network debugging may use port 5555 (adb tcpip after USB); only use that workflow when your TV explicitly documents it. Prefer Wireless Debugging on supported TVs.
Claude Desktop configuration file locations:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Create a private environment file from the example above, then configure:
{
"mcpServers": {
"stremio": {
"command": "uvx",
"args": [
"--env-file",
"/absolute/path/to/stremio.env",
"stremio-mcp-server"
]
}
}
}Replace both absolute paths:
{
"mcpServers": {
"stremio": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/stremio-mcp",
"run",
"--env-file",
"/absolute/path/to/stremio-mcp/.env",
"stremio-mcp"
]
}
}
}Restart the MCP client after changing configuration. You can instead place the variables directly in the client configuration's env object, but that file must remain private.
Variable | Required for | Sensitive | Description |
| Playback and TV tools | Local network detail | Android TV IP address |
| Playback and TV tools | No | Current ADB connection port; defaults to legacy |
|
| Yes | TMDB credential. A v4 read access token is sent as an |
|
| Yes | Account token used for Stremio library reads and writes; sent in the HTTPS request body only |
| Optional | No | Native ADB executable; defaults to |
Features initialize independently. For example, TMDB search works without a TV connection, while direct IMDb playback does not require TMDB. Leave STREMIO_AUTH_KEY empty to disable library access.
Every HTTP request uses one shared async client with explicit timeouts, a bounded response size, and a bounded connection pool, so a slow or unreachable service cannot stall other tool calls or device controls. The defaults are safe; override them only when a slow link makes them too tight. An unparsable or out-of-range value is reported by variable name and replaced with the default.
Variable | Default | Description |
|
| Seconds to establish a connection |
|
| Seconds to wait for response data |
|
| Seconds to send request data |
|
| Seconds to wait for a pooled connection |
|
| Maximum TMDB/Cinemeta response body |
|
| Maximum Stremio library response body |
|
| Maximum simultaneous connections |
|
| Maximum simultaneous TMDB requests during a fan-out search |
Tool | Purpose | External access and side effects |
| Read-only TMDB discovery for movies/TV and IMDb IDs | Sends bounded read-only requests to TMDB; never changes the TV or account |
| Open a movie or episode by direct IMDb ID or by title | Requires ADB; title search may query TMDB or the library, opens Stremio, and attempts a center key press |
| Read the account or add/remove explicit items | Requires the Stremio auth key; only |
| Send volume, playback, navigation, or power commands | Sends commands to the physical Android TV; playback |
| Read the current Stremio playback snapshot | Reads only Stremio-scoped media-session, audio-track, uptime, and extractor diagnostics |
Use search for TMDB discovery and library with action=search for the personal Stremio collection. Use play to open content, tv_control for remote-like commands, and playback_status to inspect what is actually playing. All five tools return plain text rather than structured result objects.
Library mutations require an explicit IMDb ID and content type. Search first when a title is ambiguous; title-based play otherwise uses the first matching result. For play title searches, source=search requires both season and episode for TV; source=library can use a saved episode or default to S1E1. Direct series playback also requires both numbers. play reports an accepted Android intent, not a verified stream or center-key action.
Library reads report empty, not found, and unavailable outcomes distinctly. Mutations fail closed: add and remove abort without writing whenever the preceding read failed, returned an item whose _id is not exactly the requested ID, returned duplicate or unrequested rows, or returned an item of a different content type. Re-adding and removing are account mutations that preserve watch state; removal is a soft delete and writes are verified with a follow-up read.
search reports a TMDB outage as an error rather than as "no results". When an automatic search reaches only one of the movie and TV halves, it returns the half that succeeded and appends a (partial results — …) note. tv_control does not verify ordinary key effects; use playback_status for a snapshot, whose stalled state means a claimed PLAYING session lacked corroborating live Stremio audio. Do not send navigate/select unless Stremio has the intended focus.
Search for Dune movies from 2021.
Play movie tt1375666.
Play Breaking Bad season 1 episode 1.
Pause playback.
What's currently playing?
Search my Stremio library for Severance.
Add movie tt1375666 to my library.See the usage examples for accurate tool-level workflows and safer search-then-play examples.
Test one boundary at a time:
adb devices -l — confirms the TV connection.
Ask the MCP client to list tools — should show the five tools above.
“Search for Inception” — confirms the TMDB key and network access.
“Play movie tt1375666” — confirms ADB and Stremio deep linking.
“List my Stremio library” — optionally confirms the Stremio auth key.
The play tool confirms that Android accepted the Stremio intent, then attempts a center key press; it does not verify the key press or guarantee that an addon supplied a stream. Stremio may show a source list that requires tv_control or a physical remote.
adb disconnect TV_IP:CONNECTION_PORT
adb connect TV_IP:CONNECTION_PORT
adb devices -lConfirm the computer and TV are on the same LAN and client isolation is disabled.
Use the current connection port, not the pairing port.
Accept the authorization prompt on the TV.
If pairing is stale, forget the computer on the TV and pair again.
On macOS, grant Local Network permission under Privacy & Security → Local
Network to the adb binary itself. A reliable pattern is to start the ADB
server once from a permitted GUI terminal, then let the MCP server and other
tools act as localhost clients of that existing server.
A failure reported as local_network_denied means the MCP server itself
reached the TV over raw TCP while adb could not, so the network is fine:
apply the two macOS steps above instead of debugging routing.
Do not run adb kill-server or adb start-server from automated tooling: that
can discard a permitted server and recreate it under a process without the
required macOS permission.
Launch Stremio manually once and sign in.
Confirm that your Stremio addons provide streams for the title.
Select a source with tv_control or a physical remote.
For direct IMDb or TMDB title playback of a series, provide both season and episode; library playback can use its saved episode or default to S1E1.
Confirm the relevant key is present and has no quotes or extra spaces.
Restart the MCP client after editing .env.
Renew an expired Stremio key using the auth-key guide.
Android TV only; this server uses Android intents and ADB key events.
Playback depends on Stremio addons and may require manual source selection.
The automatic center press occurs after a fixed 2.5-second delay and may miss the expected control.
Playback metadata varies by Android device, OS version, and active player.
Modern Wireless Debugging connection ports can change.
The host must reach TMDB, Stremio, and the TV on the local network for their respective features.
The server opens these Stremio deep links through ADB:
Movie: stremio:///detail/movie/{imdb_id}/{imdb_id}
Series: stremio:///detail/series/{imdb_id}/{imdb_id}:{season}:{episode}Playback status is scoped to Stremio's media-session block. Claimed playing is corroborated with a started media AudioTrack for the session owner so Exo-player error / stale sessions are reported as stalled instead of healthy playback. Position is estimated from Android's monotonic playback clock only while playback is live, and duration may fall back to media-extractor diagnostics.
Playback stop verifies post-conditions (no active Stremio playback). When media-session stop is ignored, the server tries pause+back and, if needed, a bounded am force-stop com.stremio.one fallback, and reports failure if the session still plays.
Credential-free checks use mocks and do not contact TMDB, Stremio, or an Android device:
uv sync --locked
uv run --locked python -m unittest discover -s tests -v
uv run --locked python -m compileall -q src tests
uv buildSee CONTRIBUTING.md for the contribution workflow, CHANGELOG.md for release notes, and SECURITY.md for vulnerability reporting and credential-redaction guidance.
server.json is the metadata published to the official MCP Registry. The
canonical entry is linked in Availability.
Canonical sources for this server. Anything published elsewhere is not maintained here.
Surface | Identity | Link |
Source repository |
| |
Python package |
| |
Official MCP Registry |
| https://registry.modelcontextprotocol.io/v0.1/servers/io.github.netixc%2Fstremio-mcp/versions/latest |
Current release |
|
Treat STREMIO_AUTH_KEY like a password; it permits library reads and writes.
Network failures are logged and returned as a category, host, and status code only. Configured credentials and secret-bearing query strings are stripped from every log record and every error the server returns, including tracebacks and third-party HTTP request logs.
ADB failures are logged and returned as a bounded category with guidance only, such as unreachable, unauthorized, offline, or timeout; device endpoints, raw ADB output, and command payloads are never logged or returned.
Treat ADB authorization as device-control access and protect ~/.android/adbkey.
Never post .env, MCP client configuration, auth keys, device IPs, or ADB keys in issues or logs.
Review account and device mutations before approving them in your MCP client.
Disable Wireless Debugging and revoke credentials when they are no longer needed.
Licensed under the MIT License.
This project is not affiliated with or endorsed by Stremio, TMDB, or Anthropic. It does not provide media or bypass Stremio addon requirements. Use it only with devices and accounts you are authorized to control.
Read or mutate the Stremio library. Add/remove require an explicit IMDb ID and content type.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Required for add/remove; tv is an alias for series | |
| query | No | Title substring for search | |
| action | Yes | Library action to perform | |
| imdb_id | No | Explicit IMDb ID for check/add/remove | |
| active_only | No | Exclude soft-deleted items from list/search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It mentions 'Read or mutate' but does not describe side effects, persistence, or required permissions for mutations. Schema's 'active_only' hints at soft-delete but description omits this context.
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 sentences, no redundant words. First sentence defines scope, second adds constraint. Efficient and front-loaded.
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?
Tool has 5 parameters, multiple actions, and no output schema. Description is too minimal to cover behavioral details (return values, action-specific outcomes). Lacks completeness for an agent to reliably invoke.
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 description coverage is 100%, baseline 3. Description adds that IMDb ID and type are required for add/remove, providing context beyond schema. But other parameters (query, action, active_only) are not elaborated.
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?
Description states 'Read or mutate the Stremio library' which clearly defines the verb and resource. However, it does not distinguish from sibling tool 'search' which may overlap with the library's search action.
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?
Description provides a usage hint for add/remove actions (require IMDb ID and type) but lacks explicit guidance on when to use this tool versus alternatives like search or play.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Play movies or TV episodes. Use 'query' to search by title, or 'imdb_id' to play directly.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | movie or tv (required with query) | |
| year | No | Optional year filter | |
| query | No | Title to search and play | |
| season | No | Season number (for TV) | |
| source | No | search (TMDB) or library (Stremio) | search |
| episode | No | Episode number (for TV) | |
| imdb_id | No | IMDb ID (e.g., tt0111161) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It states it 'plays' content but omits side effects (e.g., starting playback, handling multiple results, authentication requirements). Adequate but not comprehensive.
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 sentences, front-loaded with purpose, then usage guidance. No filler.
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 7 parameters (none required) and no output schema, the description covers only the two primary modes. Does not explain parameters like year, season, episode, or source in context, nor describe expected output or errors.
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 100%; description adds value by explaining the two main invocation modes (query vs imdb_id) and their relationship, going beyond individual parameter descriptions.
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?
Clearly states verb ('play') and resource ('movies or TV episodes'), and distinguishes from sibling tools like 'search' and 'library' by implying play action.
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 explicit use cases: search by title or use IMDb ID. Lacks explicit when-not-to-use or comparison with siblings, but offers clear guidance on invocation methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current playback status. Returns app, title, state (playing/paused/stalled/stopped/none/error/unknown; stalled means the session claims playing but audio output is not live), position, and duration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains that it returns current playback status and details the 'state' field including the nuanced meaning of 'stalled'. It does not disclose authentication or rate limits, but for a read-only tool, the behavioral context is adequate.
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 sentences, with the first stating the core purpose and the second enumerating returned fields. No wasted words; efficient and clear.
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 no parameters and no output schema, the description fully covers what the tool does and returns, including state values with special explanation for 'stalled'. Complete for a simple read-only 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 description need not explain parameter semantics. It adds value by describing the return fields, which compensates for the lack of an output schema.
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 'Get' and the resource 'current playback status', and lists the specific fields returned (app, title, state, position, duration). It distinguishes from sibling tools like play, search, library, tv_control by focusing on status retrieval.
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?
Usage context is implied by the nature of the tool (getting status) compared to siblings like play (control) and search (finding content). However, no explicit guidance on when to use this vs alternatives, or when not to use it, is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for movies or TV shows. Returns results with IMDb IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | movie, tv, or auto (searches both) | auto |
| year | No | Optional year filter | |
| query | Yes | Title to search for |
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 that results include IMDb IDs but omits other behavioral traits such as read-only nature, pagination, search scope (e.g., full text vs. title), or limitations.
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 sentence that efficiently conveys the tool's purpose and key output detail. No redundant words, front-loaded with essential 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?
For a 3-parameter search tool with no annotations or output schema, the description is too sparse. It lacks usage guidelines, behavioral details (e.g., read-only, case sensitivity), and context on how search results integrate with sibling tools like play.
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 has 100% description coverage, so baseline is 3. The description adds value by mentioning that results contain IMDb IDs, which is not in the parameter descriptions, but does not further elaborate on parameter usage beyond the schema.
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 'Search for movies or TV shows' with a specific verb and resource, and mentions returning IMDb IDs, which distinguishes it from sibling tools like play, library, tv_control, and playback_status that 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?
No guidance is provided on when to use this tool versus alternatives, or when not to use it. The description merely states what it does without contextualizing usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Control Android TV. volume: up/down/mute/set. playback: play/pause/toggle/stop/next/previous/forward/rewind; stop succeeds only when playback is verified to have ended (no actively playing session), not merely when a key event is delivered. navigate: up/down/left/right/select/back/home. power: wake/sleep/toggle/status.
| Name | Required | Description | Default |
|---|---|---|---|
| value | No | Value for 'set' actions (e.g., volume 0-15) | |
| action | Yes | Action name (see tool description for valid actions per category) | |
| category | Yes | volume, playback, navigate, or power |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behavioral details: the 'stop' action only succeeds when playback is verified ended, not on mere key event delivery; volume range 0-15 for 'set'; and enumerates valid actions per category. This provides transparency beyond a simple action listing.
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 (single paragraph) and organized by category, though bullet points would improve readability. Every sentence provides useful information; 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 main functionality and a critical behavioral nuance (stop). However, lacks information on prerequisites (e.g., device must be on), error handling, what happens on invalid actions, and whether other actions besides volume set require values. Partial completeness for a tool with no output schema.
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 100%, but the description adds value by explicitly listing valid actions for each category and clarifying that 'value' is used for 'set' actions (e.g., volume). The schema's action description merely refers to tool description, so the description fills that gap.
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 controls Android TV across volume, playback, navigation, and power categories. It specifies verbs (up/down, play/pause, etc.) and resource (Android TV). However, it does not explicitly differentiate from sibling tools like 'play' or 'search', which could lead to ambiguity.
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 such as 'play' (for starting playback) or 'search'. The description lists actions but does not specify contexts where this tool is preferred or not suitable. No exclusions or alternatives mentioned.
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.0libraryplayplayback_statussearchtv_controlEach tool has a distinct primary purpose except for the search functionality in 'play' which overlaps with 'search'. However, descriptions clarify that 'search' is for discovering content while 'play' is for direct playback, so agents can distinguish with care.
Tool names are lowercase single words but mix verbs (search, play), nouns (library), and compounds (tv_control, playback_status). They lack a uniform pattern like verb_noun, though they are readable and understandable.
With 5 tools covering search, playback, library management, TV control, and playback status, the set is well-scoped for a media center MCP server. Each tool earns its place without redundancy.
The tool surface covers the core lifecycle: search, play, library CRUD, full TV control, and status monitoring. Minor gaps like missing favorites management or subtitle control exist but do not hinder typical agent workflows.
Unlock a world of television with the TV Maze MCP server. Effortlessly search for shows by name or
Trakt MCP — TV/movie metadata + watch tracking signals
Remote MCP server for Web3TV creators — manage your account over MCP.
The official MCP Server for the Mux API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/netixc/stremio-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
