# apiarya/wemo-mcp-server [Health: Active]

**Category:** 🏠 Home Automation  
**Repository:** https://github.com/apiarya/wemo-mcp-server  
**GitHub Stars:** 1  
**Views:** 4  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/apiarya-wemo-mcp-server

## Description
Control WeMo smart home devices via AI assistants using natural language. Built on pywemo for 100% local control — no cloud dependency. Supports dimmer brightness, device rename, HomeKit codes, and multi-phase discovery.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `uvx` (confidence: high):

```json
"mcpServers": {
  "wemo-mcp-server": {
    "command": "uvx",
    "args": ["wemo-mcp-server"],
    "env": {
      "WEMO_MCP_DEFAULT_SUBNET": "",
      "WEMO_MCP_SCAN_TIMEOUT": "",
      "WEMO_MCP_MAX_WORKERS": "",
      "WEMO_MCP_CACHE_ENABLED": "",
      "WEMO_MCP_CACHE_TTL": "",
      "WEMO_MCP_LOG_LEVEL": ""
    }
  }
}
```

**Requires environment variables:** `WEMO_MCP_DEFAULT_SUBNET`, `WEMO_MCP_SCAN_TIMEOUT`, `WEMO_MCP_MAX_WORKERS`, `WEMO_MCP_CACHE_ENABLED`, `WEMO_MCP_CACHE_TTL`, `WEMO_MCP_LOG_LEVEL` — the values above are empty placeholders; fill in real credentials before running (see the repository for what each one is for).

## Documentation

## What apiarya/wemo-mcp-server MCP server does

The apiarya/wemo-mcp-server MCP server exposes local WeMo device management to MCP-compatible AI assistants. It is designed for asking an assistant to find devices, inspect their state, change power or brightness, rename them, or retrieve HomeKit setup codes.

The server is built on pywemo and communicates with WeMo devices on the local network. Its documented feature set includes support for on/off, toggle, and brightness operations, along with device status reporting. It also provides persistent device caching, configurable retry behavior, and detailed network error messages.

## How it works

The server runs as a stdio MCP process. Device discovery uses multiple phases, including UPnP/SSDP and network port probing. Scans can use parallel workers, and the discovered device cache persists across restarts with a configurable time-to-live.

MCP resources expose live state through `devices://` and `device://{id}` URIs. Built-in prompts cover discovery, status reports, scene control, and troubleshooting. Elicitations can ask for clarification when a subnet or device name is ambiguous.

All device communication is local according to the project documentation; the server does not require a cloud service for WeMo control.

## Setup and configuration

The apiarya/wemo-mcp-server MCP server requires Python 3.10 or newer and uses `uvx` to launch the package. Install `uv`, then add a stdio server entry to the chosen MCP client. The quick-start command for Claude Code is:

```bash
claude mcp add wemo -- uvx wemo-mcp-server
```

The default scan range is `192.168.1.0/24`. Set `WEMO_MCP_DEFAULT_SUBNET` when devices use another subnet, such as `192.168.86.0/24`. Other documented settings control scan timeout, concurrent workers, cache behavior, cache lifetime, and log level. Configuration can be supplied through environment variables or a YAML file based on the example configuration.

After editing a client configuration, restart or reload that client as appropriate. The repository documents setup examples for Claude Desktop, Claude Code, VS Code, Cursor, Cline, Windsurf, Zed, and Continue.

## Tools and capabilities

The documented MCP tools are:

- `scan_network`: search the configured network for WeMo devices.
- `list_devices`: list devices known to the server.
- `get_device_status`: retrieve current device state and brightness information.
- `control_device`: change power state, toggle a device, or set brightness.
- `rename_device`: change a device's name.
- `get_homekit_code`: retrieve a HomeKit setup code.
- `get_cache_info`: inspect device cache information.
- `clear_cache`: remove cached device data.
- `get_configuration`: inspect the active server configuration.

The server also supplies device-state resources, guided prompts, and clarification elicitations in addition to tools.

## Limitations and notes

Discovery depends on local network reachability and the configured subnet. If the WeMo devices are on a different subnet, update the default subnet setting before scanning. Full-subnet scans can take roughly 23–30 seconds using the documented parallel scan configuration, so discovery may not be immediate.

The repository documents stdio transport; no cloud API or remote-control service is described.

_Full upstream README: https://allmcps.com/mcp/apiarya-wemo-mcp-server/readme_

