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

mcp-divoom-lan

Official
by DivoomDevelop
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

watchface_replace_dial_bg_file

Replace a Divoom watchface dial background by uploading a JPEG or WebP bitmap under 500 KiB at the model’s required dimensions, without sending archive files.

Instructions

POST /replace_clock_dial_bg using multipart (Device/ReplaceClockDialBgFile). Replaces the cached dial bitmap only and does not accept archives. Backdrop must be JPEG or WebP and less than 500 KiB. Required dimensions are selected from hardware: TimesFrame 800x1280, AstroToo 480x480. 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.
clockIdNo
fileNameNoFilename in multipart header. Defaults to basename(imagePath).
imagePathYesAbsolute or relative JPEG/WebP path. Required size: TimesFrame 800x1280 or AstroToo 480x480; file must be less than 500 KiB.
filePartNameNoSecond multipart part name. Default is current UTC ms timestamp.
useCurrentDisplayClockNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.3.0
    • changedInput schema / properties / imagePath / description
      Previous value: -"Absolute or relative image file path. Backdrop must be JPEG (FF D8) or WebP (RIFF…WEBP); PNG/GIF are rejected. Recommended 800x1280, ≤ 500 KiB."New value: +"Absolute or relative JPEG/WebP path. Required size: TimesFrame 800x1280 or AstroToo 480x480; file must be less than 500 KiB."
    • 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

B3.4/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden, and it does substantial work: it discloses that only the cached bitmap is replaced, that archives are rejected, and that the payload must be JPEG/WebP under 500 KiB. It omits whether the replacement is reversible, permission/auth requirements, and failure behavior, keeping it short of a 5.

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?

The most important constraint (what the endpoint does and what it refuses) is front-loaded, and most sentences carry a constraint rather than filler. The trailing 'Legacy 800x1280 examples and typography apply only to TimesFrame' is cryptic and partially redundant with the dimension rules stated earlier.

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 six-parameter mutation tool with no annotations and no output schema, the description covers hardware targeting, format, and size but leaves clockId, useCurrentDisplayClock, and the response shape unaddressed. It is workable for a confident caller but leaves real gaps for one unfamiliar with the device family.

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

Parameters2/5

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

Schema coverage sits at 67%, and the description's parameter-adjacent content (image format, size, TimesFrame 800x1280 / AstroToo 480x480) largely repeats what the imagePath schema field already says. Two parameters, clockId and useCurrentDisplayClock, are undocumented in both the schema and the description, leaving the agent to guess at their meaning.

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 names a specific operation (replacing the cached dial bitmap) plus the exact endpoint and transport (POST /replace_clock_dial_bg, multipart). The clause 'does not accept archives' implicitly separates it from the generic upload sibling, but no sibling is named explicitly, so differentiation rests on inference.

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 a real precondition workflow ('For AstroToo, first query hardware/capabilities; use the 480x480 AstroToo resources'), which is useful ordering guidance. However, it never states when to use this tool instead of watchface_upload_file or watchface_create_local_clock, and gives no when-not conditions.

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