Skip to main content
Glama
DivoomDevelop

mcp-divoom-lan

Official

watchface_create_local_clock

Create and upload a custom local clock watchface to a Divoom LAN device by providing a backdrop image and clock element metadata.

Instructions

POST /create_local_clock (multipart) — Device/CreateLocalClock. metadata.DialAssets accepts 'auto' (default; sniffs gzip magic on the file part), 'image' (single JPEG/WebP backdrop), or 'bundle' (clock_bg.tar.gz). Legacy UseDialAssetBundle (0=image, non-0=bundle) is honored when DialAssets is omitted. Backdrop is JPEG/WebP only; element slots inside the tarball accept JPEG/WebP/PNG (firmware wf_validate_bundle_slot_image_file). Each ItemList[i] needs disp/font/x/y/w/h/size/alig numbers and color_1/color_2/item_id non-empty strings; ItemIdList must be a parallel non-empty string array. alig: 3=center, 4=left, 5=right. Pointer slots DIVOOM_CLOCK_DISP_SUPPORT_HOUR_POINT_IMAGE=131, MIN_POINT_IMAGE=132, SECOND_POINT_IMAGE=233: mandatory shared square w=h and identical x,y,w,h on all three rows; w×w bitmaps; center pivot, hand toward 12 o'clock — never full-screen 800×1280 layers or mismatched thin rects; reference ClockId 60012 export. transp: MUST use 100 for visible layers — LLMs often emit 0 → invisible on device. hier: ONLY 0=auto, 1=bottom, 2=top (no tier 3+). See docs/tool-examples.md §5b. Uniqueness: do not duplicate the same image-backed disp in one dial — later rows overwrite earlier ones; especially NET_PIC family (disp 13, 125–130, 173–175, DIVOOM_CLOCK_DISP_SUPPORT_NET*_PIC); see docs/disp-usage.md. Multipart framing (Content-Length per part): see watchface_upload_file description.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNoOptional per-call target override. If omitted, environment variables are used.
imagePathYesEither 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.
metadataYesFirst 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.
filePartNameNoSecond multipart part name. Default is current UTC ms timestamp.
fileNameNoFilename in multipart header. Defaults to basename(imagePath).
Behavior5/5

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

With no annotations, the description carries full burden and is exceptionally transparent. It details DialAssets modes, legacy handling, slot constraints, pointer requirements, transparency settings, hierarchy rules, and uniqueness warnings. All critical behaviors are disclosed.

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

Conciseness3/5

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

The description is very long and dense, containing extensive technical details. While structured in a logical flow, it could be more concise to improve readability without losing critical 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?

Given the tool's complexity (5 parameters, nested objects, no output schema), the description is remarkably complete. It covers almost every aspect of usage, from multipart framing to specific slot requirements and common pitfalls.

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 100%, but the description adds significant value by explaining valid values, legacy behavior, and constraints beyond the schema. For example, it clarifies DialAssets options, image format restrictions, and pointer slot rules.

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 clearly states the tool's action (create local clock via POST multipart) and the resource. However, it does not explicitly distinguish from sibling tools like watchface_patch_local or watchface_replace_dial_bg_file, missing some differentiation.

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 explicit guidance on when to use this tool versus alternatives. The description is purely technical and does not provide context on scenarios or prerequisites.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DivoomDevelop/mcp-divoom-lan'

If you have feedback or need assistance with the MCP directory API, please join our Discord server