OpenHue CLI を使用して、Claude やその他の LLM インターフェイスを通じて Philips Hue ライトを制御できる MCP サーバー。
Node.js (v16 以上)
Claude for Desktop （オプション、テスト用）
Related MCP server: Philips Hue MCP Service
サーバーを使用する前に、Hue ブリッジで OpenHue CLI を設定する必要があります。
セットアップ コマンドを実行します。
# 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 setup画面上の指示に従います。
CLIはHueブリッジを検索します
プロンプトが表示されたら、Hueブリッジのリンクボタンを押します。
セットアップが完了したことを確認するまで待ちます
ライトをリストしてセットアップを確認します。
# 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 lightsライトがリストに表示されたら、セットアップは完了しており、MCP サーバーを使用する準備が整っています。
リポジトリをクローンします。
git clone <your-repo-url>
cd claude-mcp-openhue依存関係をインストールします:
npm installプロジェクトをビルドします。
npm run buildサーバーを実行します。
npm startこのサーバーは、MCP を通じて次の機能を公開します。
すべてのライトを一覧表示するか、特定のライトの詳細を取得します
ライトのオン/オフ
明るさを調整する
色を設定する
色温度を制御する
すべての部屋を一覧表示するか、部屋の詳細を取得します
部屋のすべての照明をまとめて制御
部屋全体の明るさと色を設定する
利用可能なシーンを一覧表示する
さまざまなモードでシーンをアクティブにする
部屋別にシーンをフィルタリング
Claude Desktop 構成ファイルを開きます。
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
サーバー構成を追加します。
{
"mcpServers": {
"hue": {
"command": "node",
"args": ["/absolute/path/to/build/index.js"]
}
}
}Claudeデスクトップを再起動します
サーバーが接続されていることを確認するには、ハンマーアイコンを探します
接続すると、次のような自然言語の質問を Claude に尋ねることができます。
「リビングルームにはどんな照明がありますか？」
「キッチンの電気を全部つけて」
「寝室の照明を50%の明るさに設定してください」
「オフィスの照明を青に変えてください」
「『リラックス』シーンを有効にする」
「書斎ではどんなシーンが楽しめますか？」
すべてのライトを一覧表示したり、特定のライトの詳細を取得したりします
{
lightId?: string; // Optional light ID or name
room?: string; // Optional room name filter
}個々のライトを制御する
{
target: string; // Light ID or name
action: "on" | "off";
brightness?: number; // 0-100
color?: string; // Color name
temperature?: number; // 153-500 Mirek
}すべての部屋を一覧表示したり、特定の部屋の詳細を取得したりします
{
roomId?: string; // Optional room ID or name
}部屋のすべての照明を制御します
{
target: string; // Room ID or name
action: "on" | "off";
brightness?: number;
color?: string;
temperature?: number;
}利用可能なシーンを一覧表示します
{
room?: string; // Optional room name filter
}特定のシーンをアクティブにする
{
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 startDockerが実行中であることを確認する
OpenHue 構成が存在することを確認する
Claude Desktopのログを確認する
OpenHue CLIを直接実行してみる
OpenHue CLI の権限を確認する
ライト/部屋/シーン名を確認する
Dockerコンテナのログを確認する
Hue ブリッジの接続を確認する
MITライセンス
リポジトリをフォークする
機能ブランチを作成する
変更をコミットする
ブランチにプッシュする
新しいプルリクエストを作成する
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0activate-scenecontrol-lightcontrol-roomget-lightsget-roomsget-scenesScored across 6 tools
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.
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.
Create projects, nodes, and tasks in UluP Spaces by conversation with Claude.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Your apps, skills, MCP servers and keys from ahel.ai, served to Claude, ChatGPT, Cursor and Codex.
