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

mcp-divoom-lan

Official
by DivoomDevelop
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

watchface_create_local_clock

Creates or updates the MCP-managed local watchface on a Divoom LAN device by injecting the managed clock slot, uploading a JPEG/WebP backdrop, and handling TimesFrame or AstroToo asset rules.

Instructions

Upsert the MCP-managed local watchface with multipart. The server injects its managed ClockId, reads that slot first, creates it only when missing, and otherwise updates it. Callers do not provide a ClockId. TimesFrame accepts DialAssets image/auto/bundle and may use clock_bg.tar.gz. AstroToo accepts DialAssets=image only: upload every element separately with watchface_upload_file, put each returned local:// FileId in ItemList[i].image_addr, then call this tool with one 480x480 JPEG/WebP backdrop. AstroToo rejects TAR/TGZ/ZIP, UseDialAssetBundle!=0, and bundle_image. 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.
fileNameNoFilename in multipart header. Defaults to basename(imagePath).
metadataYesFirst multipart JSON: ClockName, ItemList, ItemIdList. Omit ClockId; the MCP server injects the managed slot automatically. AstroToo requires DialAssets=image and local:// image_addr values from prior per-file uploads. TimesFrame may use auto/image/bundle and legacy UseDialAssetBundle.
imagePathYesSingle JPEG/WebP backdrop (TimesFrame 800x1280; AstroToo 480x480; less than 500 KiB). TimesFrame also supports clock_bg.tar.gz. AstroToo never accepts an archive here.
filePartNameNoSecond multipart part name. Default is current UTC ms timestamp.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.3.0
    • changedInput schema / properties / imagePath / description
      Previous value: -"Either a single JPEG/WebP dial backdrop (recommend 800x1280, ≤ 500 KiB) or a `clock_bg.tar.gz` USTAR+gzip archive. Tar contents: required `clock_bg.jpg|webp` at the root plus one file per local leaf referenced by `ItemList[i].image_addr` (no subdirs, leaf basenames ≤ 95 bytes). Leaves may be JPEG/WebP/PNG; non-supported sources should be transcoded client-side."New value: +"Single JPEG/WebP backdrop (TimesFrame 800x1280; AstroToo 480x480; less than 500 KiB). TimesFrame also supports clock_bg.tar.gz. AstroToo never accepts an archive here."
    • changedInput schema / properties / metadata / description
      Previous value: -"First multipart JSON: `ClockName`, `ItemList`, `ItemIdList`. Optional `DialAssets` (`auto`|`image`|`bundle`) or legacy `UseDialAssetBundle` (0/!=0). In bundle mode, `ItemList[i].bundle_image` is an alias for `image_addr` leaf and is also accepted. Tool minifies the JSON before sending."New value: +"First multipart JSON: ClockName, ItemList, ItemIdList. Omit ClockId; the MCP server injects the managed slot automatically. AstroToo requires DialAssets=image and local:// image_addr values from prior per-file uploads. TimesFrame may use auto/image/bundle and legacy UseDialAssetBundle."
    • 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

A4.6/5.0
Behavior5/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 so well: it discloses that the server injects ClockId, reads the slot first, creates only when missing, and otherwise updates. It also lists hard rejections (AstroToo rejects TAR/TGZ/ZIP, UseDialAssetBundle!=0, bundle_image) and file constraints (<500 KiB, 480x480 vs 800x1280).

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?

Information-dense and front-loaded with the upsert semantics. Slightly hurt by run-on sentences and the repeated 'For AstroToo' framing that could be consolidated, but every sentence carries substantive constraints.

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 mutation tool with no annotations and no output schema, the description covers the required preconditions, per-model constraints, injected values, and rejection cases. An agent has enough to invoke it correctly on either model family.

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 100%, so a baseline 3 applies, but the description adds real meaning beyond the schema: callers must not provide ClockId, metadata DialAssets must be 'image' for AstroToo with local:// image_addr values, and imagePath dimensions differ per model.

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?

Opens with a specific verb+resource: 'Upsert the MCP-managed local watchface with multipart.' It also distinguishes the operation from sibling tool watchface_upload_file, which it correctly positions as a prerequisite for element uploads rather than an alternative.

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?

Gives explicit model-specific workflows: 'For AstroToo, first query hardware/capabilities' and 'upload every element separately with watchface_upload_file... then call this tool.' It doesn't explicitly contrast with watchface_patch_local or watchface_replace_dial_bg_file, so there's no explicit when-not clause, but the prerequisites are clear.

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