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

mcp-divoom-lan

Official
by DivoomDevelop
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

watchface_upload_file

Uploads one local asset file per call to AstroToo watchface staging, returning a temporary FileId that must be bound via create or patch before reboot.

Instructions

AstroToo-only POST /upload_local_asset with one multipart file. Assets must be sent serially, one file per call, using Device/UploadLocalAsset metadata. Each success returns a temporary local:// FileId which must be bound by a successful create or patch; firmware then atomically moves the staging file into durable watchface storage. Unbound uploads are cleared on reboot and are never uploaded outward. TAR/TGZ/ZIP are rejected. The product photo/pixel POST /upload route is kept separate. TimesFrame generic /upload is blocked in MCP local-only mode; use create/patch multipart assets instead. 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(filePath).
filePathYes
metadataYes
filePartNameNoSecond multipart part name. Default is current UTC ms timestamp.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.0
    • 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.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it explains the temporary local:// FileId return, atomic move into durable storage on binding, cleanup of unbound uploads on reboot, and the guarantee that unbound uploads are never sent outward. It also discloses rejected archive formats and prerequisite hardware/capability checks.

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 definition is front-loaded with the core action and is dense with relevant constraints rather than filler. It is somewhat long and run-on for a single paragraph, but each sentence contributes routing, lifecycle, or prerequisite information useful to an agent.

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

Completeness4/5

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

For a complex upload tool with no annotations and no output schema, the description is largely complete: it covers routing, binding lifecycle, cleanup behavior, rejected file types, and device prerequisites. It still leaves some parameter-level detail, especially metadata structure and filePath semantics, to the schema.

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?

The schema has only 60% description coverage, but the description adds meaning by specifying that metadata must use Device/UploadLocalAsset semantics and that uploads are one multipart file per call. It does not fully explain the required filePath or the metadata object's internal fields, so some semantic gaps remain.

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?

The description starts with a specific verb/resource pair: "AstroToo-only POST /upload_local_asset with one multipart file." It clearly distinguishes this upload path from create/patch binding, the product photo/pixel upload route, and TimesFrame generic upload, so an agent can identify its exact purpose among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states serial one-file-per-call uploads, the required Device/UploadLocalAsset metadata, and that each upload must be bound by a successful create or patch. It also names alternatives and exclusions, including blocked TimesFrame generic upload and the separate product photo route.

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