Which integrations are available for this server?

Allows controlling Philips Hue lights via Bluetooth LE, providing tools to turn on/off, set brightness, color temperature, RGB color, and apply scenes.

How do I use io.github.jonnyblankinship/hue-ble-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@io.github.jonnyblankinship/hue-ble-mcp Turn on the reading light and set it to warm white" 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.

io.github.jonnyblankinship/hue-ble-mcp

by jonnyblankinship

Overview Schema Source Related Servers Discussions Admin

Python

Local

hue-ble-mcp

An MCP server that lets Claude control Philips Hue lights via Bluetooth LE — no Hue Bridge or internet connection required.

Just ask Claude things like:

"Turn off the light"
"Set the light to a warm reading mode"
"Make it a deep blue"
"Dim it to 20%"

Tools

Tool	Description
`scan_hue_lights`	Discover nearby Hue BLE lights and get their addresses
`turn_on`	Turn a light on
`turn_off`	Turn a light off
`set_brightness`	Set brightness 1–100%
`set_color_temperature`	Set white color temperature (2000K warm → 6500K cool)
`set_color`	Set RGB color
`get_light_state`	Read current power, brightness, and color mode
`set_scene`	Apply a preset: `relax`, `energize`, `concentrate`, `reading`, `nightlight`, `bright`

Related MCP server: Nordic Thingy:52 MCP Server

Requirements

macOS (uses CoreBluetooth via bleak)
Python 3.10+
A Philips Hue light with Bluetooth support (most lights made after 2019)
Claude Desktop

Installation

Option 1: pip (recommended)

pip install hue-ble-mcp

Then add to your ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "hue-ble": {
      "command": "hue-ble-mcp",
      "env": {
        "HUE_LIGHT_ADDRESS": ""
      }
    }
  }
}

Option 2: Clone and run

git clone https://github.com/jonnyblankinship/hue-ble-mcp.git
cd hue-ble-mcp
python3 -m venv venv
./venv/bin/pip install -r requirements.txt

Then add to your claude_desktop_config.json:

{
  "mcpServers": {
    "hue-ble": {
      "command": "/absolute/path/to/hue-ble-mcp/venv/bin/python",
      "args": ["/absolute/path/to/hue-ble-mcp/server.py"],
      "env": {
        "HUE_LIGHT_ADDRESS": ""
      }
    }
  }
}

First-time setup

1. Pair your light

Hue BLE lights need to be in pairing mode the first time you connect. The easiest way is to reset the light via the Hue app (Settings → Light setup → select light → Delete), which puts it back into factory pairing mode.

After the first successful connection, macOS remembers the bond and you won't need to do this again.

2. Find your light's address

Restart Claude Desktop, then ask:

"Scan for my Hue lights"

Claude will return something like:

[
  {
    "name": "Signe gradient floor",
    "address": "77577FFA-2F08-CAFD-5F3C-5C1824D8C362"
  }
]

On macOS, addresses are UUIDs (not MAC addresses). This is normal — CoreBluetooth assigns its own identifiers.

3. Set the default address

Paste the address into HUE_LIGHT_ADDRESS in your config and restart Claude Desktop. From then on, you don't need to specify the address in every command.

"env": {
  "HUE_LIGHT_ADDRESS": "77577FFA-2F08-CAFD-5F3C-5C1824D8C362"
}

How it works

Philips Hue lights broadcast over Bluetooth LE using a proprietary but well-documented GATT profile. This server writes directly to those GATT characteristics using bleak, bypassing the need for a Hue Bridge or the Hue cloud entirely.

Key characteristics used:

UUID	Function
`932c32bd-0002-...`	Power (on/off)
`932c32bd-0003-...`	Brightness
`932c32bd-0004-...`	Color temperature (mireds)
`932c32bd-0005-...`	XY color (CIE 1931)

RGB colors are converted to CIE 1931 XY space using the wide RGB D65 gamut matrix before being sent to the light.

Limitations

macOS only — Linux should work too but is untested. Windows is not supported.
Bluetooth range — must be within ~10m of the light.
One adapter per light — the light bonds to the Bluetooth adapter used during first pairing. A different Mac won't be able to connect without re-pairing.
Multiple lights — supported, just call each tool with the specific address. Set HUE_LIGHT_ADDRESS to your primary light for convenience.

License

MIT

Available Tools

8 tools

get_light_stateA

Read the current state of a Philips Hue light (power, brightness, color mode).

Args: address: Bluetooth address from scan_hue_lights. Leave blank to use HUE_LIGHT_ADDRESS env var.

ParametersJSON Schema

Name	Required	Description	Default
`address`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description bears full burden. It declares read-only operation, which is non-destructive. However, it does not mention rate limits, error behavior, or handling of unreachable lights. For a simple read, this is adequate but not exceptional.

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?

Extremely concise: two-line docstring plus a summary sentence. Every sentence provides useful information without redundancy. Front-loaded with purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values need not be explained. Description covers purpose and parameter usage. Lacks error handling or edge case info, but adequate for a simple read operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no parameter descriptions in schema), but the description explains the address parameter's source (scan_hue_lights) and default behavior (env var fallback), adding significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Read' and resource 'state of a Philips Hue light', listing key attributes (power, brightness, color mode). It clearly distinguishes from sibling tools that perform mutations like turn_on or set_brightness.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides guidance that address comes from scan_hue_lights and can be omitted for an environment variable. Implicitly sets context for when to use this tool (after scanning, for reading). Lacks explicit when-not-to-use or alternatives, but sufficient for a simple tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scan_hue_lightsA

Scan for Philips Hue BLE lights nearby and return their names and addresses. Run this first to find your light's Bluetooth address — you'll need it for all other tools.

On macOS, addresses look like UUIDs (e.g. 'BEF1AF5D-9A4D-4C2B-8870-1AB7CC5CE8DD'). This is normal — macOS CoreBluetooth uses its own identifiers instead of MAC addresses.

Args: timeout: How many seconds to scan (default 10). Increase if your light isn't found.

ParametersJSON Schema

Name	Required	Description	Default
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description adds transparency about macOS UUID behavior and timeout adjustment. Could explicitly state non-destructive nature, but scan implies no side 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?

Three short paragraphs: purpose, usage guidance, parameter detail. Efficiently front-loads key information with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Fully describes tool's function, prerequisite role, platform nuance, and parameter behavior. Output schema exists, so return values need no further explanation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only parameter timeout is explained: purpose (scan time), default (10), and advice (increase if light not found). Adds meaning beyond schema's type/default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action ('Scan for Philips Hue BLE lights nearby') and the output ('return their names and addresses'). Distinct from sibling tools like get_light_state or set_brightness.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to run this first to obtain the Bluetooth address needed for all other tools. Provides platform-specific note and timeout advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_brightnessA

Set the brightness of a Philips Hue light (turns it on if off).

Args: brightness: Brightness as a percentage, 1–100. address: Bluetooth address from scan_hue_lights. Leave blank to use HUE_LIGHT_ADDRESS env var.

ParametersJSON Schema

Name	Required	Description	Default
`brightness`	Yes
`address`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description discloses the key side effect of turning the light on if off. Also specifies brightness range (1-100). Lacks details on permissions or error handling, but sufficient for a simple tool.

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?

Two sentences plus parameter docs front-load the purpose. Every sentence adds value with zero redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple setter with 2 parameters and no nested objects, the description covers behavior, parameter usage, and has an output schema (not shown). Complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, so the description adds critical meaning: brightness is a percentage (1-100) and address comes from scan_hue_lights or env var. This significantly aids correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Set') and resource ('brightness of a Philips Hue light'), and clearly distinguishes it from siblings like turn_on and set_color by mentioning the turn-on side effect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states that it turns the light on if off, indicating when to use it. Provides guidance for the address parameter (from scan_hue_lights or env var). Does not explicitly mention when not to use it, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_colorA

Set the color of a Philips Hue light using RGB values. Switches the light to color mode. Use set_color_temperature to go back to white mode.

Args: red: Red channel, 0–255 green: Green channel, 0–255 blue: Blue channel, 0–255 address: Bluetooth address from scan_hue_lights. Leave blank to use HUE_LIGHT_ADDRESS env var.

ParametersJSON Schema

Name	Required	Description	Default
`red`	Yes
`green`	Yes
`blue`	Yes
`address`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that the tool switches the light to color mode. However, it does not mention potential side effects (e.g., overriding previous color, whether it turns on the light if off) or any permissions or rate limits.

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 very concise: 4 sentences plus an Args section. It front-loads the main action, distinguishes from a sibling, and lists parameters with clear semantics. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of an output schema (not shown), the description covers purpose, usage distinction, parameter semantics, and address guidance. It does not mention return values (not needed due to output schema), but could add a note about the light's state (e.g., whether it turns on automatically).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description adds full semantic meaning: red, green, blue are RGB values 0–255; address is a Bluetooth address from scan_hue_lights or the HUE_LIGHT_ADDRESS env var. This compensates entirely for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it sets the color of a Philips Hue light using RGB values, and explicitly distinguishes from the sibling tool set_color_temperature by noting that it switches to color mode and that set_color_temperature returns to white mode.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool (to set color) and when to use set_color_temperature instead. It also provides guidance on the address parameter, referencing scan_hue_lights. However, it does not mention prerequisites like the light being on or other context-specific conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_color_temperatureA

Set the color temperature of a Philips Hue light. Switches the light to white/CT mode (disables any color).

Args: kelvin: Color temperature in Kelvin. 2000K = very warm candlelight 2700K = warm white (typical bulb) 4000K = neutral / office white 6500K = cool daylight address: Bluetooth address from scan_hue_lights. Leave blank to use HUE_LIGHT_ADDRESS env var.

ParametersJSON Schema

Name	Required	Description	Default
`kelvin`	Yes
`address`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description effectively discloses the side effect of disabling color and switching modes. It also explains kelvin values with examples, though it doesn't mention error handling or device state requirements.

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 concise: one sentence for the action, then clear bullet-like arg details. No superfluous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two parameters and an output schema, the description covers the purpose, side effects, parameter semantics, and usage context completely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description adds thorough meaning: kelvin is explained with typical values and address gets a clear explanation including the env var fallback.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sets color temperature of a Philips Hue light and switches to white/CT mode, distinguishing it from set_color which handles hue/saturation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (for white light) versus set_color (for colored light) by noting it disables color. It also provides guidance on the address parameter with an env var fallback, but lacks explicit 'use instead of X' statements.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_sceneA

Apply a preset lighting scene to a Philips Hue light.

Available scenes: relax - Dim warm amber, great for winding down energize - Bright cool white, boost alertness concentrate - Bright neutral white, focus mode reading - Warm white at comfortable reading level nightlight - Very dim warm red, minimal sleep disruption bright - Full brightness daylight white

Args: scene: Scene name (case-insensitive) address: Bluetooth address from scan_hue_lights. Leave blank to use HUE_LIGHT_ADDRESS env var.

ParametersJSON Schema

Name	Required	Description	Default
`scene`	Yes
`address`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It only mentions applying a scene and address sourcing, omitting side effects, state changes, or error conditions.

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 concise with a clear introductory sentence and a list of scenes. Every sentence adds value; no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers required information (scenes, address) and leverages the output schema for return values. Slightly incomplete on success/failure behavior, but adequate for the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates fully: enumerates available scenes with effects, explains address usage (from scan_hue_lights or env var), adding meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Apply a preset lighting scene to a Philips Hue light.' It lists specific scene names with descriptions, distinguishing it from sibling tools like set_brightness or set_color.

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 when to use (to apply a scene) but lacks explicit when-not or alternative guidance. It doesn't contrast with siblings like set_brightness for precise control.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

turn_offA

Turn off a Philips Hue light.

Args: address: Bluetooth address from scan_hue_lights. Leave blank to use HUE_LIGHT_ADDRESS env var.

ParametersJSON Schema

Name	Required	Description	Default
`address`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/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. It only states that it turns off the light, a mutation, but lacks details on side effects or prerequisites beyond the address. For a simple action, this is minimally adequate but not comprehensive.

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: a one-line purpose and a brief parameter explanation. Every sentence serves a purpose with no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter, output schema exists), the description covers the main aspects. It could mention error cases or state behavior if already off, but overall it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds meaning by explaining that the address comes from 'scan_hue_lights' and can be omitted to use an environment variable. This compensates for the schema's lack of description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Turn off a Philips Hue light,' which is a specific verb+resource pair. It distinguishes itself from sibling tools like 'turn_on' and 'set_brightness' by indicating the action of turning off.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the address parameter and that it can be left blank to use an environment variable. However, it does not explicitly state when not to use this tool or compare it to alternatives, though the context is straightforward.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

turn_onB

Turn on a Philips Hue light.

Args: address: Bluetooth address from scan_hue_lights. Leave blank to use HUE_LIGHT_ADDRESS env var.

ParametersJSON Schema

Name	Required	Description	Default
`address`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

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. It only states the action without disclosing side effects, idempotency, prerequisites, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise with a clear 'Args' section; effectively communicates parameter details in minimal text, though no additional formatting or prioritization.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema, return values are covered. However, the description lacks context about prerequisites, when to use, and behavior in edge cases, which is minimally adequate for a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description explains the 'address' parameter: its source (scan_hue_lights) and fallback behavior (env var), adding essential meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Turn on a Philips Hue light,' specifying the action and resource, and distinguishes from sibling tools like turn_off and set_brightness.

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?

No guidance on when to use this tool versus alternatives; only mentions the address source from scan_hue_lights, but does not provide usage context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.1.3Jun 11, 2026
- First observedget_light_state
- First observedscan_hue_lights
- First observedset_brightness
- First observedset_color
- First observedset_color_temperature
- First observedset_scene
- First observedturn_off
- First observedturn_on

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-06-12 16:03 across 8 tools

Disambiguation5/5

Each tool has a distinct, non-overlapping purpose: scanning, state reading, toggling power, setting brightness, color, color temperature, and scenes. No ambiguity in tool selection.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., scan_hue_lights, set_brightness, turn_off). No mixing of conventions.

Tool Count5/5

8 tools is well-scoped for controlling a single Hue light via BLE. Each function is necessary and none feel extraneous.

Completeness5/5

Covers all core operations: discovery, state reading, on/off, brightness, color, color temperature, and preset scenes. No obvious gaps for single-light control.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Blynk IoT PlatformOAuth
cloud.blynk
Manage your IoT device fleet directly from Claude. Create device templates with datastreams and events, provision new devices, read live sensor data, and control outputs. The Blynk connector integrates with the Blynk IoT platform, enabling direct configuration and monitoring of connected devices and infrastructure.
Home Automation & IoT Agent Orchestration App Automation
2
WHOOP — MissingMCPOAuth
com.missingmcp
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.
Health & Wellness Fitness Tracking
25
platform7nOAuth
tech.p7n
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Communication Project Management Workplace & Productivity
2
SimStim
ai.simstim
Deploy sims to any screen. Control your displays with Claude.
App Automation Virtualization OS Automation
2

Related MCP Servers

OpenHue MCP Server
Home Automation & IoT App Automation
lsemenenko
A
license
A
quality
D
maintenance
Enables control of Philips Hue lights through Claude and other LLM interfaces using the OpenHue CLI.
Updated 2 years ago (2024-12-24 15:50 UTC)
6
10
MIT
Nordic Thingy:52 MCP Server
Home Automation & IoT App Automation Command Line
karthiksuku
F
license
Not graded
quality
Not graded
maintenance
Enables Claude to control Nordic Thingy:52 IoT devices via Bluetooth LE, allowing users to manage LED colors, play sounds, and read environmental sensors through natural language conversations.
Updated a year ago (2025-10-11 04:57 UTC)
-
Philips Hue MCP Server
Home Automation & IoT App Automation
pedrof
F
license
Not graded
quality
D
maintenance
Enables AI assistants to control Philips Hue smart lighting systems, including individual lights, groups, scenes, brightness, and color adjustments through natural language commands.
Updated 9 months ago (2025-12-21 03:31 UTC)
-
Philips Hue MCP Service
Home Automation & IoT
plwp
A
license
Not graded
quality
D
maintenance
Enables control of Philips Hue lights through the Model Context Protocol, providing tools for turning lights on/off, setting brightness and color, and retrieving light status.
Updated a year ago (2025-06-14 07:01 UTC)
1
Apache 2.0