Skip to main content
Glama
DivoomDevelop

mcp-divoom-lan

Official

watchface_patch_local

Patch a local watchface on a Divoom device by editing metadata fields or uploading a new backdrop image or clock bundle.

Instructions

Patch local dial via Device/PatchLocalClockInfo with precheck. Defaults to POST /divoom_api (JSON only) for pure metadata edits. Prefer ItemPatchList (per-index field diff) — DO NOT include item_id inside patch.* unless the user explicitly asks to rename a slot, since the firmware will overwrite the device-side item_id and break menu/config bindings. When dialAssetsPath is set, switches to multipart POST /patch_local_clock: first JSON part (Device/PatchLocalClockInfo, optional DialAssets), second part single JPEG/WebP dial backdrop or clock_bg.tar.gz bundle. Element slots inside the tarball must be JPEG, WebP, or PNG (validated by firmware wf_validate_bundle_slot_image_file). Use ItemPatchList[].patch.bundle_image= to bind a tar leaf to that slot's img_addr; supplying ItemList alone is a full-table replace and should be avoided unless the row count actually changes. Pointer fixes (131/132/233 = DIVOOM_CLOCK_DISP_SUPPORT_*_POINT_IMAGE): shared square x/y/w/h, w×w PNGs, center rotation; ref ClockId 60012; transp 100; hier 0/1/2 only — docs/tool-examples.md §5b. Avoid duplicate image-backed disp rows (NET_PIC family); docs/disp-usage.md. Multipart framing: watchface_upload_file description and resources/skill-quick-reference.md.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNoOptional per-call target override. If omitted, environment variables are used.
clockIdNo
useCurrentDisplayClockNo
deviceImageUrlNo
devicePreviewImageUrlNo
devicePreviewImageUrl2No
setColorListNo
itemListNo
itemIdListNo
itemPatchListNo
itemPatchByRoleListNo
dialAssetsPathNoOptional second multipart part. Either a single JPEG/WebP dial backdrop (`clock_bg.jpg|webp`, validated by divoom_watchface_replace_clock_dial_bg_validate_saved_file) or a `clock_bg.tar.gz` bundle. The tarball may contain `clock_bg.jpg|webp` plus the leaves listed by `ItemPatchList[].patch.bundle_image`. Element leaves inside the tar may be JPEG/WebP/PNG (PNG is element-only; backdrop must be JPEG/WebP). When set, the tool POSTs `/patch_local_clock` with the firmware-strict multipart layout.
filePartNameNoMultipart field name for dialAssetsPath part. Default is current UTC ms timestamp.
fileNameNoMultipart filename header for dialAssetsPath. Defaults to basename(dialAssetsPath).
Behavior4/5

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

Given no annotations, the description covers many behavioral aspects: default POST method, switching to multipart when dialAssetsPath is set, validation by firmware, warnings about item_id breaking bindings, and pointer fix details. It lacks rate limits or side effects but is generally transparent.

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

Conciseness2/5

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

The description is a dense wall of text with no paragraph breaks or structure. It is not front-loaded and contains tangential details. Could be significantly streamlined and organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the tool's complexity (14 parameters, nested objects, no output schema), the description omits return values and does not cover several parameters. It provides deep detail on specific aspects but is incomplete overall.

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 description coverage is only 29%. The description elaborates on dialAssetsPath and some aspects of itemPatchList, but many parameters (e.g., clockId, useCurrentDisplayClock, deviceImageUrl, setColorList, itemIdList) are not explained. The description fails to compensate for low schema coverage.

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 patches local dial via Device/PatchLocalClockInfo with precheck, and distinguishes two modes (JSON-only for metadata, multipart for assets). However, it does not explicitly differentiate from sibling tools like watchface_create_local_clock or watchface_replace_dial_bg_file, leaving some ambiguity.

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?

Internal usage guidance is provided (prefer ItemPatchList, avoid item_id in patches), but there is no high-level statement on when to use this tool versus siblings, nor conditions 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