OpenHue MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![openhue-mcp-server MCP server](https://glama.ai/mcp/servers/lsemenenko/openhue-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/lsemenenko/openhue-mcp-server)

Score Badge

Copy to your README.md:

[![openhue-mcp-server MCP server](https://glama.ai/mcp/servers/lsemenenko/openhue-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/lsemenenko/openhue-mcp-server)

Latest Blog Posts

Lightport: Open-Sourcing Glama's AI Gateway
By punkpeye on April 27, 2026.
open source
OpenAI
Tool Definition Quality Score (TDQS)
By punkpeye on April 3, 2026.
mcp
The Hackers Who Tracked My Sleep Cycle
By punkpeye on March 26, 2026.
security

MCP directory API

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