govee-mcp

A LAN-first, cloud-fallback Model Context Protocol (MCP) server for Govee smart devices. Point an AI agent, or any MCP client, at your Govee lights, plugs, and appliances and control them by name.

It is built to run on a home network. It prefers local LAN control for lights (fast, no internet, no rate limits) and falls back to Govee's cloud API for plugs, appliances, and anything not reachable on the LAN.

Status and spirit

This is a v0 that works for me on my own network. It is shared in the spirit of "here is something that works with an agent on my home network, have it, make it yours, and harden it as you please." It is not a supported product. Issues and pull requests are welcome, but treat it as a starting point rather than a finished appliance.

What it does (v0)

• Discovers your devices (cloud account list plus a LAN scan) and addresses them by friendly name.
• Controls power, brightness, RGB color, and white color temperature.
• Reads current device state (power, brightness, color).
• Lists and applies dynamic scenes (preset effects), fetched live per device (cloud-only).
• Groups devices so one command (on/off, color, scene, state) applies to every member.
• Prefers LAN for LAN-capable lights and falls back to the cloud for everything else.
• Stays under Govee's published cloud limits (100 requests per minute, 10000 per day) with a client-side guard.

What it does not do yet (the "harden it" list)

• Bluetooth temperature and humidity sensors (for example the H5075). Those are read over BLE, not the cloud or LAN API, and are the most interesting next step.
• Per-segment color, music mode, and DIY effects. Scenes are supported; these are the remaining cloud capabilities.
• Real-time push state (Govee's AWS IoT channel).

These are deliberately left as room to grow.

How it compares

The existing Govee MCP servers are thin: one is cloud-only and controls a single hardcoded device with three tools; another is LAN-only and lights-only. This one does multi-device discovery, both transports with automatic selection, state read-back, and cloud rate-limit handling.

Requirements

• Python 3.10 or newer.
• A Govee API key for cloud control (optional, but needed for plugs, appliances, and non-LAN devices). Get one in the Govee Home app: Profile, then About Us, then Apply for API Key.
• For LAN control: enable "LAN Control" on each device in the Govee Home app, and make sure UDP ports 4001, 4002, and 4003 can pass on your network.

Install

From source:

git clone https://github.com/evefromwayback/govee-mcp.git
cd govee-mcp
pip install -e .

This installs a govee-mcp command. To run without installing:

PYTHONPATH=src python3 -m govee_mcp

Configure

Copy .env.example to .env and fill in what you need, or set the variables in your MCP client config.

Command-line use

A small CLI ships alongside the server and uses the same engine, so it is the fastest way to confirm things work before wiring up an MCP client. Start with doctor.

govee doctor                   # check key, cloud, and LAN connectivity
govee devices                  # list devices (instant, from cache)
govee refresh                  # re-scan devices and show current state
govee state                    # full current state for every device
govee state "Desk Lamp"        # full current state for one device
govee on "Desk Lamp"
govee off "Desk Lamp"
govee brightness "Desk Lamp" 40
govee color "Desk Lamp" 255 0 0
govee temp "Desk Lamp" 4000
govee scenes "Desk Lamp"       # list this device's scenes
govee scene "Desk Lamp" "Sunrise"
govee groups                   # list device groups
govee group "Living Room" "Bulb 1" "Bulb 2"   # create or replace a group
govee ungroup "Living Room"    # delete a group

Run govee help, or just govee with no arguments, for the command reference. doctor reports whether your key loaded, how many devices are on your cloud account, and how many answered on the LAN, with a hint for whatever is missing. If govee is not on your PATH, use python3 -m govee_mcp.cli ... instead.

Any device name in the control commands can also be a group name. Define a group with govee group "Living Room" "Bulb 1" "Bulb 2", then govee on "Living Room", govee color "Living Room" 255 0 0, or govee state "Living Room" apply to every device in it. Groups are stored in ~/.config/govee-mcp/groups.json (override with GOVEE_GROUPS_PATH).

govee devices is instant: it lists devices from the cache and makes no live calls. govee refresh re-scans your devices and then prints the live state of all of them. govee state (with or without a name) is always a live read.

Connect an MCP client

Claude Desktop (claude_desktop_config.json), installed command:

{
  "mcpServers": {
    "govee": {
      "command": "govee-mcp",
      "env": { "GOVEE_API_KEY": "your-key-here" }
    }
  }
}

Running from source instead:

{
  "mcpServers": {
    "govee": {
      "command": "python3",
      "args": ["-m", "govee_mcp"],
      "env": {
        "GOVEE_API_KEY": "your-key-here",
        "PYTHONPATH": "/absolute/path/to/govee-mcp/src"
      }
    }
  }
}

Use with Hermes Agent

Hermes Agent has a native MCP client, so this server drops in. Once it is in the Hermes catalog, install it by name:

hermes mcp install govee

To wire it manually, add it under mcp_servers in your Hermes config and put GOVEE_API_KEY in your Hermes .env (the server process inherits it):

mcp_servers:
  govee:
    command: govee-mcp

If govee-mcp is not on the launch PATH, use its absolute path or python3 -m govee_mcp. A Hermes catalog manifest is included at hermes/manifest.yaml.

Tools

• list_devices(): discovered devices with names, supported actions, and transports. Call this first.
• list_groups(): device groups and their members.
• create_group(name, devices): create or replace a group.
• delete_group(name): delete a group.
• get_device_state(name): current power, brightness, and color.
• refresh(): re-scan devices and return the live state of all of them.
• set_power(name, on): turn on or off.
• set_brightness(name, level): 0 to 100.
• set_color(name, red, green, blue): each channel 0 to 255.
• set_color_temp(name, kelvin): roughly 2000 (warm) to 9000 (cool).
• list_scenes(name): the dynamic scenes (preset effects) a device supports.
• set_scene(name, scene): apply a scene by name. Call list_scenes first to get valid names.

Every control tool's name can be a single device or a group name (see list_groups); a group applies the action to all its members.

Scenes (the "patterns": Sunrise, Aurora, and so on) are cloud-only and differ per device, so they need an API key and are fetched live from each device rather than hardcoded. The other actions work over both transports. Each control tool returns a structured result. A change is only real when the tool returns ok=true; the tool descriptions instruct the model not to claim a change happened without a successful call.

How transport selection works

On each action the registry picks a transport:

1. If the device was found on the LAN, LAN control is preferred (local and unmetered) for the light actions it supports.
2. Otherwise the cloud API is used. This is required for plugs, appliances, and devices without LAN control.

Set GOVEE_PREFER_LAN=false to always use the cloud, or disable a transport entirely with GOVEE_LAN_ENABLED=false or GOVEE_CLOUD_ENABLED=false.

API terms and when you need a key

Govee's cloud Developer API is free but, per Govee, for non-commercial use only. You may not use it for profit-making purposes or charge anyone for an implementation built on it. That restriction is on the cloud service and applies to whoever supplies the key, not to this code. Personal home use and sharing this project for free are both fine. Do not build a paid product on the free key without arranging commercial terms with Govee. See Govee's API service terms: https://app-h5.govee.com/common/api-service-item

You do not always need a key:

• LAN mode needs no key and never contacts Govee's servers. If you only have lights, enable LAN Control on each one and run with GOVEE_CLOUD_ENABLED=false.
• The key is what lets the server reach devices Govee does not expose over the LAN (plugs, appliances), fall back when a light is not reachable on the LAN, and pull friendly names and capabilities from your account. LAN discovery alone only returns a MAC, an IP, and a model number.

Security notes, and on vendoring vs cloning

• This server takes no third-party device library as a runtime dependency. The Govee LAN and cloud protocols are reimplemented here from Govee's public protocol documentation. The only runtime dependency is the official MCP SDK (MIT). That keeps the supply-chain surface tiny: you run your own code plus one well-known SDK.
• If you extend this with an existing Govee library later (for example for Bluetooth sensors), prefer vendoring a pinned, inspected copy over depending on it live. Vendoring means you read exactly what runs, it cannot change under you, and you can trim it to what you need. The cost is that you own its updates. Only vendor permissively licensed code, since vendoring copyleft code would relicense this project.
• Your API key is read from the environment and never logged. Do not commit your .env.
• LAN control uses unauthenticated UDP on your local network, which is how Govee's LAN API works. Keep IoT devices on a trusted or segmented network.
• No telemetry. The server talks only to your devices and, when used, Govee's API.

Testing

pip install -e ".[test]"
pytest

The tests mock the cloud HTTP layer and run a local fake Govee device over UDP, so they need no API key and no real hardware.

License and attribution

MIT. See LICENSE.

The protocols were implemented from Govee's public LAN guide and Developer API v2 documentation. Thanks to the open-source projects that mapped this territory first (govee2mqtt and govee-led-wez, homebridge-govee, and the Govee BLE sensor projects). No code was copied from them; they are credited as references.

Roadmap

• v1: Bluetooth sensor reads (temperature and humidity), per-segment color, music mode, and optional real-time state.