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

mcp-divoom-lan

Official
by DivoomDevelop
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

watchface_get_fonts_local

Retrieves a Divoom device's local font list for watchface design, so you can choose compatible fonts before rendering text on the target screen.

Instructions

Call Device/GetLocalFontList. 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.

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

C2.9/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose one meaningful trait: output depends on device model (AstroToo 480x480 resources vs. legacy TimesFrame 800x1280). However, it never states that this is a read-only retrieval, what happens on an unreachable device, or how results are shaped, which is a notable gap for an unannotated tool.

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?

Three tight sentences with no filler, front-loaded with the endpoint being invoked. It is dense and slightly cryptic in phrasing ('Legacy 800x1280 examples and typography apply only to TimesFrame'), but every sentence carries model-specific information.

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 read tool with no annotations, no output schema, and a nested target object, the description covers model selection and a discovery prerequisite but omits return-value shape, read-only safety, and fallback behavior. It is minimally sufficient to attempt a call but leaves an agent guessing about results.

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

Parameters3/5

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

Schema description coverage is 100% and every nested target field (host, port, model, hardware, timeoutMs) is documented in the schema itself, so the baseline applies. The description adds only a model caveat that acts more as a workflow instruction than parameter clarification, and does not explain how target.model/hardware interact with this specific call.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description leads with the underlying endpoint name 'Device/GetLocalFontList', which implies retrieving the font list from the device, but it never states in plain language what the tool returns or how it differs from the sibling watchface_font_catalog. An agent can mostly infer purpose from the tool name plus endpoint, so it is adequate but not self-evidently distinguished from alternatives.

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?

The only usage guidance is model-conditional ('For AstroToo, first query hardware/capabilities') and a scoping note that legacy 800x1280 assets apply only to TimesFrame. There is no statement of when to use this versus watchface_font_catalog or watchface_get_local, and no exclusion conditions for callers.

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