Bond MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BOND_HOST | Yes | The IP address of your Bond Bridge | |
| LOG_LEVEL | No | Logging level (DEBUG, INFO, WARNING, ERROR) | INFO |
| BOND_TOKEN | Yes | Your Bond API token (obtained from Bond Home app) | |
| BOND_TIMEOUT | No | Connection timeout in seconds | 10.0 |
| BOND_MAX_RETRIES | No | Maximum number of connection retries | 3 |
| BOND_RETRY_DELAY | No | Delay between retries in seconds | 1.0 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_devicesA | List all Bond devices connected to the bridge. Returns: Dictionary containing all devices with their basic information. |
| get_device_infoB | Get detailed information about a specific device. Args: device_id: The Bond device identifier Returns: Detailed device information including capabilities and properties. |
| get_device_stateB | Get current state of a Bond device. Args: device_id: The Bond device identifier Returns: Current device state including power, speed, direction, etc. |
| toggle_device_powerC | Toggle power state of a Bond device (on/off). Args: device_id: The Bond device identifier Returns: Result of the toggle operation. |
| set_fan_speedA | Set fan speed for a ceiling fan device. Args: device_id: The Bond fan device identifier speed: Fan speed level (0-8, where 0 is off) Returns: Result of the speed change operation. |
| set_fan_directionA | Set fan direction for a ceiling fan device. Args: device_id: The Bond fan device identifier direction: Fan direction ("forward" or "reverse") Returns: Result of the direction change operation. |
| control_shadesB | Control motorized shades. Args: device_id: The Bond shade device identifier action: Action to perform ("open", "close", or "set_position") position: Position percentage (0-100) when action is "set_position" Returns: Result of the shade control operation. |
| set_light_brightnessA | Set brightness for a dimmable light device. Args: device_id: The Bond light device identifier brightness: Brightness percentage (0-100, where 0 is off) Returns: Result of the brightness change operation. |
| send_custom_actionB | Send a custom action to a Bond device. Args: device_id: The Bond device identifier action: Bond action name (e.g., "TurnOn", "TurnOff", "SetSpeed") argument: Optional argument for the action Returns: Result of the custom action. |
| get_bridge_infoA | Get Bond Bridge information and status. Returns: Bridge information including version, uptime, and configuration. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools have distinct purposes targeting specific device types or actions, but some overlap exists: 'control_shades' and 'send_custom_action' could be confused for shade operations, and 'toggle_device_power' might overlap with custom actions for power control. Descriptions help clarify, but agents might misselect between these in edge cases.
Tool names follow a consistent verb_noun pattern throughout, using snake_case uniformly. Examples include 'get_bridge_info', 'list_devices', 'set_fan_speed', and 'toggle_device_power', making them predictable and easy to understand.
With 10 tools, this server is well-scoped for controlling Bond devices like shades, fans, and lights. Each tool serves a clear function, such as retrieving information, listing devices, or performing specific actions, without being overly sparse or bloated.
The toolset provides good coverage for device control, including CRUD-like operations (list, get, control) and specific actions for common devices. A minor gap is the lack of a dedicated tool for creating or deleting devices, but agents can likely work around this using existing tools like 'send_custom_action' or bridge configurations.