The OpenHue MCP Server allows you to control Philips Hue lights through Claude and other LLM interfaces.
Lights Control: List all lights, get specific light details, turn lights on/off, adjust brightness (0-100%), set colors by name, and control color temperature (153-500 Mirek)
Room Control: List all rooms, get room details, control all lights in a room together, set room-wide brightness and colors
Scene Management: List available scenes (filterable by room), and activate scenes with different modes (active, dynamic, or static)
Provides comprehensive control of Philips Hue lighting systems through the OpenHue CLI, including turning lights on/off, adjusting brightness, setting colors, controlling color temperature, managing rooms, and activating scenes.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OpenHue MCP Server turn on the living room lights to 50% brightness"
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.
An MCP server that enables control of Philips Hue lights through Claude and other LLM interfaces using the OpenHue CLI.
Node.js (v16 or higher)
Claude for Desktop (optional, for testing)
Related MCP server: Philips Hue MCP Service
Before using the server, you need to set up the OpenHue CLI with your Hue Bridge:
Run the setup command:
# On Linux/macOS:
docker run -v "${HOME}/.openhue:/.openhue" --rm --name=openhue -it openhue/cli setup
# On Windows (PowerShell):
docker run -v "${env:USERPROFILE}\.openhue:/.openhue" --rm --name=openhue -it openhue/cli setupFollow the on-screen instructions:
The CLI will search for your Hue Bridge
Press the link button on your Hue Bridge when prompted
Wait for confirmation that the setup is complete
Verify the setup by listing your lights:
# On Linux/macOS:
docker run -v "${HOME}/.openhue:/.openhue" --rm --name=openhue -it openhue/cli get lights
# On Windows (PowerShell):
docker run -v "${env:USERPROFILE}\.openhue:/.openhue" --rm --name=openhue -it openhue/cli get lightsIf you see your lights listed, the setup is complete and you're ready to use the MCP server.
Clone the repository:
git clone <your-repo-url>
cd claude-mcp-openhueInstall dependencies:
npm installBuild the project:
npm run buildRun the server:
npm startThis server exposes the following capabilities through MCP:
List all lights or get specific light details
Turn lights on/off
Adjust brightness
Set colors
Control color temperature
List all rooms or get room details
Control all lights in a room together
Set room-wide brightness and colors
List available scenes
Activate scenes with different modes
Filter scenes by room
Open your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the server configuration:
{
"mcpServers": {
"hue": {
"command": "node",
"args": ["/absolute/path/to/build/index.js"]
}
}
}Restart Claude Desktop
Look for the hammer icon to verify the server is connected
Once connected, you can ask Claude natural language questions like:
"What lights do I have in the living room?"
"Turn on all the lights in the kitchen"
"Set the bedroom lights to 50% brightness"
"Change the office lights to blue"
"Activate the 'Relaxing' scene"
"What scenes are available in the den?"
Lists all lights or gets details for specific lights
{
lightId?: string; // Optional light ID or name
room?: string; // Optional room name filter
}Controls individual lights
{
target: string; // Light ID or name
action: "on" | "off";
brightness?: number; // 0-100
color?: string; // Color name
temperature?: number; // 153-500 Mirek
}Lists all rooms or gets specific room details
{
roomId?: string; // Optional room ID or name
}Controls all lights in a room
{
target: string; // Room ID or name
action: "on" | "off";
brightness?: number;
color?: string;
temperature?: number;
}Lists available scenes
{
room?: string; // Optional room name filter
}Activates a specific scene
{
name: string; // Scene name or ID
room?: string; // Optional room name
mode?: "active" | "dynamic" | "static";
}.
├── src/
│ └── index.ts # Main server implementation
├── build/ # Compiled JavaScript
├── package.json
├── tsconfig.json
└── README.mdnpm run buildnpm startCheck that Docker is running
Verify OpenHue configuration exists
Check Claude Desktop logs
Try running OpenHue CLI directly
Check OpenHue CLI permissions
Verify light/room/scene names
Check Docker container logs
Verify Hue Bridge connectivity
MIT License
Fork the repository
Create your feature branch
Commit your changes
Push to the branch
Create a new Pull Request
Activate a specific scene
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Optional scene mode | |
| name | Yes | Scene name or ID | |
| room | No | Optional room name for the scene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Activate' implies a state-changing operation, but the description doesn't mention what activation entails (does it turn on lights? adjust settings? affect multiple devices?), whether it requires specific permissions, what happens if the scene doesn't exist, or what the expected outcome is. For a mutation tool with zero annotation coverage, this is insufficient.
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 extremely concise at just three words. It's front-loaded with the essential action and resource. There's zero wasted language or redundancy. While it may be too brief for completeness, as a standalone statement it's perfectly efficient.
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 scene activation tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what scene activation means in this context, what the expected outcome is, how it differs from direct device control, or what happens upon successful/failed activation. The agent would need to guess about the tool's behavior and appropriate usage scenarios.
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%, so the schema already documents all three parameters (name, mode, room) with their descriptions and constraints. The description adds no parameter information beyond what's in the schema. With complete schema coverage, the baseline is 3 even when the description provides no additional parameter context.
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 'Activate a specific scene' clearly states the action (activate) and resource (scene), making the basic purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'control-light' or 'control-room' - the agent might not understand when to use scene activation versus direct device control. The purpose is clear but lacks sibling differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'control-light', 'control-room', and 'get-scenes', the agent needs to know when scene activation is appropriate versus direct device control or scene retrieval. No when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Control a specific Hue light
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Turn light on or off | |
| brightness | No | Optional brightness level (0-100) | |
| color | No | Optional color name (e.g., 'red', 'blue') | |
| target | Yes | Light ID or name | |
| temperature | No | Optional color temperature in Mirek |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states 'Control a specific Hue light' without elaborating on effects, permissions, rate limits, or error conditions. It doesn't clarify if changes are immediate, reversible, or require specific authentication. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a tool with well-documented parameters in the schema. Every word earns its place.
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 mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, error handling, or return values. While the schema covers parameters well, the description fails to compensate for the lack of annotations and output schema, leaving gaps in understanding the tool's full context.
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%, so all parameters are documented in the schema. The description adds no additional meaning beyond implying 'control' involves the parameters listed. It doesn't explain interactions between parameters (e.g., if 'color' overrides 'temperature') or provide usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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 'Control a specific Hue light' clearly states the verb (control) and resource (Hue light), making the purpose immediately understandable. It distinguishes from siblings like 'activate-scene' or 'get-lights' by focusing on individual light control rather than scenes or retrieval operations. However, it doesn't specify what 'control' entails beyond the schema parameters.
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?
The description provides no guidance on when to use this tool versus alternatives like 'control-room' or 'activate-scene'. It doesn't mention prerequisites (e.g., needing light IDs from 'get-lights'), exclusions, or comparative contexts. The agent must infer usage solely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Control all lights in a room
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Turn room lights on or off | |
| brightness | No | Optional brightness level (0-100) | |
| color | No | Optional color name | |
| target | Yes | Room ID or name | |
| temperature | No | Optional color temperature in Mirek |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'control all lights in a room', implying a write/mutation operation, but doesn't specify permissions needed, side effects (e.g., if it overrides individual light settings), error handling, or rate limits. This is a significant gap for a tool with potential destructive effects.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 the tool's complexity (controlling multiple lights with multiple parameters), lack of annotations, and no output schema, the description is insufficient. It doesn't address behavioral aspects like permissions, side effects, or return values, leaving critical gaps for safe and effective tool invocation.
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?
The schema description coverage is 100%, providing clear documentation for all 5 parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain how 'brightness' interacts with 'action' or clarify 'target' formats). The baseline score of 3 is appropriate when the schema does the heavy lifting.
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 ('control') and resource ('all lights in a room'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'control-light' (individual light control) or 'activate-scene' (scene-based control), which would be needed for a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives like 'control-light' or 'activate-scene'. It lacks context about prerequisites (e.g., room identification) or exclusions, leaving the agent to infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Hue lights or get details for a specific light
| Name | Required | Description | Default |
|---|---|---|---|
| lightId | No | Optional light ID or name to get specific light details | |
| room | No | Optional room name to filter lights |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes a read operation ('List' and 'get details'), which implies it's non-destructive, but fails to mention any behavioral traits such as authentication needs, rate limits, error handling, or what the return format looks like (e.g., list structure or detail fields). This leaves significant gaps for an agent to understand how to interact with it effectively.
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, efficient sentence that front-loads the core functionality ('List all Hue lights or get details for a specific light') with zero wasted words. It's appropriately sized for the tool's complexity and gets straight to the point, making it easy to parse quickly.
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 the lack of annotations and output schema, the description is incomplete for a tool with two parameters and no structured output information. It doesn't explain what the return values look like (e.g., a list of light objects or a single light object), how errors are handled, or any dependencies like authentication. For a read operation with moderate complexity, this leaves too much undefined for reliable agent use.
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%, so the schema already documents both parameters ('lightId' and 'room') with clear descriptions. The description adds marginal value by hinting at the dual functionality (listing vs. retrieving details) related to 'lightId', but doesn't provide additional syntax, format details, or clarify interactions between parameters beyond what the schema states. This meets the baseline for high schema coverage.
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 tool's purpose with specific verbs ('List' and 'get details') and resources ('Hue lights' or 'specific light'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-rooms' or 'get-scenes' beyond mentioning lights specifically, which is a minor gap.
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?
The description implies usage through its phrasing ('List all... or get details for a specific light'), suggesting it can be used for both listing and retrieving details. However, it provides no explicit guidance on when to use this tool versus alternatives like 'control-light' or 'get-rooms', nor does it mention prerequisites or exclusions, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all rooms or get details for a specific room
| Name | Required | Description | Default |
|---|---|---|---|
| roomId | No | Optional room ID or name to get specific room details |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool's actions (list and get details) but doesn't describe behavioral traits such as whether it's read-only, requires authentication, has rate limits, or what the return format looks like. This is a significant gap for a tool with no annotation coverage.
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, efficient sentence that clearly states the tool's dual functionality. It is front-loaded with the core purpose and uses no unnecessary words, making it easy to parse quickly.
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 the tool's complexity (dual functionality with a parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like safety, permissions, or return values, leaving gaps that could hinder an AI agent's ability to use the tool effectively.
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?
The input schema has 100% description coverage, with the parameter 'roomId' documented as 'Optional room ID or name to get specific room details'. The description adds minimal value beyond the schema by implying the parameter's role in switching between list and details modes, but doesn't provide additional syntax or format details. Baseline 3 is appropriate given high schema coverage.
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 tool's purpose with specific verbs ('List all rooms' and 'get details for a specific room') and identifies the resource ('rooms'). It distinguishes between two modes of operation (list vs. details), though it doesn't explicitly differentiate from sibling tools like 'get-lights' or 'control-room'.
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?
The description implies usage guidelines by mentioning two scenarios (listing all rooms vs. getting specific details), but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get-lights' for light information or 'control-room' for room control. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all scenes or get details for specific scenes
| Name | Required | Description | Default |
|---|---|---|---|
| room | No | Optional room name to filter scenes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists or gets details, implying a read-only operation, but doesn't address permissions, rate limits, pagination, or error handling. The description is minimal and lacks behavioral context beyond the basic purpose.
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 extremely concise and front-loaded, consisting of a single sentence that efficiently conveys the core functionality. There is no wasted language, and it immediately communicates the tool's dual modes of operation.
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 the lack of annotations and output schema, the description is incomplete for a tool with potential complexity (e.g., listing vs. detailing scenes, filtering). It doesn't explain return values, error conditions, or behavioral nuances, leaving significant gaps for the agent to navigate.
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?
The input schema has 100% description coverage, with the single parameter 'room' documented as 'Optional room name to filter scenes'. The description adds no additional meaning beyond this, such as format examples or filtering logic, so it meets the baseline for high schema coverage without compensating value.
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 tool's purpose with specific verbs ('List all scenes' and 'get details for specific scenes') and identifies the resource ('scenes'). It distinguishes between two modes of operation, though it doesn't explicitly differentiate from sibling tools like 'get-lights' or 'get-rooms'.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get-lights' or 'get-rooms', nor does it specify contexts where this tool is preferred or excluded, leaving the agent to infer usage based on the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: activate-scene targets scene activation, control-light and control-room handle light control at different granularities, and the get-* tools retrieve specific resource types. There is no overlap in functionality, making tool selection straightforward for an agent.
All tool names follow a consistent verb-noun pattern with hyphen separation (e.g., activate-scene, control-light, get-lights). The naming is uniform across all tools, with no deviations in style or convention, ensuring predictability and readability.
With 6 tools, the server is well-scoped for managing Philips Hue devices. The count is appropriate, covering core operations like control and retrieval for lights, rooms, and scenes without being overly sparse or bloated, fitting typical home automation workflows.
The toolset provides solid coverage for the Hue domain, including control and retrieval for lights, rooms, and scenes. A minor gap exists in missing update or delete operations for scenes or rooms, but agents can still accomplish most common tasks with the available tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lsemenenko/openhue-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
