Skip to main content
Glama
Sign In
mcp-divoom-lan

mcp-divoom-lan

Official
by DivoomDevelop
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

watchface_set_clock_select

Selects the active clock face by ID on a Divoom LAN device and suppresses an active traditional clock schedule on TimesFrame devices for the current period.

Instructions

Call Channel/SetClockSelectId with ClockId. TimesFrame queues a pair of identical requests in one serialized MCP operation so a manual selection suppresses an active traditional clock schedule for its current period; AstroToo sends it once. For AstroToo, first query hardware/capabilities; use the 480x480 AstroToo resources. Legacy 800x1280 examples and typography apply only to TimesFrame.

Input Schema

NameRequiredDescriptionDefault
targetNoOptional per-call target override. If omitted, environment variables are used.
clockIdYes
sysUpdateTimeNoOptional device clock revision. Omitted by default to preserve the original TimesFrame request shape.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.3.0
    • addedInput schema / properties / sysUpdateTime
      Added value: +{
+  "description": "Optional device clock revision. Omitted by default to preserve the original TimesFrame request shape.",
+  "type": "integer"
+}
    • addedInput schema / properties / target / properties / hardware
      Added value: +{
+  "description": "Explicit PIXOO64 90/92/96 or TimeGate 400/402 profile for direct LAN control. Must match the actual device; this is not a firmware version.",
+  "enum": [
+    90,
+    92,
+    96,
+    400,
+    402
+  ],
+  "type": "integer"
+}
    • addedInput schema / properties / target / properties / model
      Added value: +{
+  "default": "auto",
+  "description": "PIXOO64/TimeGate use discovery Hardware or target.hardware; TimesFrame/AstroToo query Hardware on the device.",
+  "enum": [
+    "auto",
+    "timesframe",
+    "astrotoo",
+    "pixoo64",
+    "timegate"
+  ],
+  "type": "string"
+}
    • removedInput schema / properties / target / properties / port / default
      Removed value: -9000
    • changedInput schema / properties / target / properties / port / description
      Previous value: -"Device HTTP port, commonly 9000."New value: +"Optional HTTP port override. Defaults to 80 for PIXOO64 90/92 and TimeGate 400, otherwise 9000."
  2. First observedv0.1.6

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does add real behavioral detail: the queued duplicate request on TimesFrame, its side effect of suppressing an active traditional clock schedule for the current period, and single-send behavior on AstroToo. It still omits failure modes and whether the change is persistent or reversible.

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?

Three sentences, front-loaded with the operation call, then device-specific behavior, then resource guidance. Dense but every clause carries information; only the trailing 'legacy 800x1280' sentence feels tacked on.

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?

For a multi-device select operation with no annotations and no output schema, the description covers the important device divergence but leaves gaps: the source and validation of clockId, sysUpdateTime's effect, and what a caller gets back on success or failure.

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 coverage is 67% and clockId — the one required parameter — has no schema description; the description only repeats 'with ClockId' and never explains where to obtain a valid id (e.g., via watchface_clock_catalog). The nested target fields are already well documented in the schema, so the description adds little beyond baseline.

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 first sentence names the concrete protocol operation (Channel/SetClockSelectId) and its key argument (ClockId), which maps to a specific verb-and-resource. However, it never plainly states in user terms that this activates a clock face on a device, and it does not distinguish itself from the sibling timegate_select_clock.

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?

It gives useful device-specific context: on TimesFrame the request is queued as a pair to suppress an active traditional clock schedule, on AstroToo it is sent once, and AstroToo requires first querying hardware/capabilities. But it never says when to choose this over timegate_select_clock or watchface_raw_command, nor which clockId sources are valid.

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

Deploy Server

Other Tools