OpenHue CLI를 사용하여 Claude 및 기타 LLM 인터페이스를 통해 Philips Hue 조명을 제어할 수 있는 MCP 서버입니다.
Node.js (v16 이상)
데스크톱용 Claude (선택 사항, 테스트용)
Related MCP server: Philips Hue MCP Service
서버를 사용하기 전에 Hue Bridge로 OpenHue CLI를 설정해야 합니다.
설치 명령을 실행합니다.
지엑스피1
화면의 지침을 따르세요.
CLI는 Hue Bridge를 검색합니다.
메시지가 표시되면 Hue Bridge의 링크 버튼을 누르세요.
설정이 완료되었는지 확인할 때까지 기다리세요.
조명을 나열하여 설정을 확인하세요.
# 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 Desktop을 다시 시작하세요
서버가 연결되었는지 확인하려면 망치 아이콘을 찾으세요.
연결되면 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 Bridge 연결 확인
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.
