Smart Appliance MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| discover_devicesB | Discover smart appliances on the local network and remember their provider adapter. |
| list_known_devicesA | List devices discovered during this MCP server session. |
| diagnose_discoveryA | Explain current discovery state and next checks without asking users for technical setup. |
| get_device_controlsB | Return available controls for a discovered device. |
| discover_appsC | Probe app launch targets exposed by a discovered media appliance. |
| search_appsA | Search all apps exposed by a discovered media appliance, including app names, package ids, categories, and launchability. |
| control_deviceD | Control a discovered device. The server routes the command through the adapter found during discovery. |
| search_contentB | Search content or installed apps on a discovered media appliance using its discovered adapter. |
| suggest_contentB | Suggest content to watch based on a discovered media appliance and optional viewing prompt. |
| record_watch_eventA | Record watch activity so recommendations can avoid repeats and learn category/app preferences. |
| list_watch_historyC | List recent watch history from the TV adapter when available, merged with local MCP history. |
| recommend_contentB | Rank what to watch next using watch history, categories, freshness, apps, and discovered launchability. |
| format_recommendation_cardsC | Format recommendations as chat-renderable cards with preview links and MCP action links instead of buttons. |
| get_device_stateA | Return current state for a discovered device when the discovered adapter supports it. |
| pair_deviceA | Start consumer pairing for a discovered device when its provider supports pairing. |
| complete_pairingA | Complete consumer pairing for a discovered device using the code shown by the appliance. |
| list_pairingsA | List locally stored consumer pairings. |
| remove_pairingB | Remove a locally stored consumer pairing. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Most tools target a distinct action/resource (discovery, pairing, device control, media recommendations). Minor overlap exists between suggest_content and recommend_content, and between search_content and search_apps, but descriptions clarify different inputs and purposes.
All tools use a consistent snake_case verb-first naming convention (list_, discover_, get_, control_, pair_, search_, suggest_, etc.). No mixed styles or arbitrary names; resource nouns follow verbs predictably.
At 18 tools the surface is on the heavy side for a single server, covering several subdomains (discovery, pairing, media, device control). The tools are not redundant enough to cut, but the count is above the ideal 3-15 range.
The server covers the full pairing lifecycle and core discovery/control/media workflow with no dead ends. Minor gaps like explicit device forgetting or media playback commands are absent, but adapters likely make those device-specific.