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

mcp-divoom-lan

Official
by DivoomDevelop
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

watchface_font_catalog

Returns a curated, filterable font catalog with IDs, script/style tags, and scenario recommendations so agents can choose valid watchface fonts deterministically.

Instructions

Return a curated font catalog so agents can pick ItemList[i].font ids deterministically. Each entry includes id, type (1=TTF, 0=image-font), display name, original charset, derived script (digits / digits-extended / latin / cjk), style tags (sans/serif/pixel/digital/handwriting/display/decorative/bold/light/etc), and recommendedFor (scenario names like time_digits / temperature_digits / weather_text / user_text / lunar_text). The response also includes a scenarios map that lists which disp ids each scenario covers and which tags to prefer. For visual style and mood per font id, read MCP resource divoom://font/guide first. Use the optional filters to narrow the result. Always cross-check with watchface_get_fonts_local before committing a font id to a real device, because the on-device font list may be a subset. For AstroToo, first query hardware/capabilities; use the 480x480 AstroToo resources. Legacy 800x1280 examples and typography apply only to TimesFrame.

Input Schema

NameRequiredDescriptionDefault
idsNoReturn only the entries whose id is in this list (useful after watchface_get_fonts_local).
tagNoMatch a single style tag (e.g., 'pixel', 'digital', 'handwriting', 'sans', 'serif', 'cjk-capable').
typeNoFilter by font type. Default 'all'.
limitNoMax number of font entries to return (default 50, max 200).
modelNoFor offline authoring only. A connected target's hardware determines its model.
scriptNoFilter by derived script. 'digits' = image fonts whose charset is exactly 0-9.
targetNoOptional per-call target override. If omitted, environment variables are used.
idsOnlyNoIf true, return only `[{id, name, type_name, script}]` rows for a compact summary.
scenarioNoFilter to fonts whose `recommendedFor` includes this scenario (see top-level `scenarios` map for the full list).
includeScenariosNoIf true (default), include the top-level `scenarios` map in the response so the agent can map disp ids → preferred tags.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.3.0
    • addedInput schema / properties / model
      Added value: +{
+  "description": "For offline authoring only. A connected target's hardware determines its model.",
+  "enum": [
+    "timesframe",
+    "astrotoo"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / script / enum
      Previous value: -[
-  "all",
-  "digits",
-  "digits-extended",
-  "latin",
-  "cjk"
-]New value: +[
+  "all",
+  "digits",
+  "digits-extended",
+  "latin",
+  "cjk",
+  "unicode"
+]
    • addedInput schema / properties / target
      Added value: +{
+  "additionalProperties": false,
+  "description": "Optional per-call target override. If omitted, environment variables are used.",
+  "properties": {
+    "hardware": {
+      "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"
+    },
+    "host": {
+      "description": "Device LAN IP. Example: 192.168.1.120",
+      "type": "string"
+    },
+    "model": {
+      "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"
+    },
+    "port": {
+      "description": "Optional HTTP port override. Defaults to 80 for PIXOO64 90/92 and TimeGate 400, otherwise 9000.",
+      "type": "integer"
+    },
+    "timeoutMs": {
+      "default": 45000,
+      "description": "HTTP timeout in milliseconds.",
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}
  2. First observedv0.1.6

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does so well: it discloses that results are curated rather than authoritative (the on-device list may be a subset) and enumerates the response fields including the `scenarios` map. It stops short of stating whether filters combine or how `limit` truncation behaves, which leaves a small residual unknown.

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?

Front-loaded with the purpose and return shape, then the caveats, which is the right order. The trailing AstroToo/480x480 and TimesFrame 800x1280 notes are relevant but slightly verbose for a catalog tool and dilute the core message.

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?

Ten parameters including a nested `target` object and no output schema, yet the description compensates by describing the returned fields and the `scenarios` map in detail. Remaining gaps (filter combination semantics, truncation) are minor given that the schema documents each parameter.

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%, so the schema already documents `ids`, `tag`, `scenario`, `idsOnly`, `includeScenarios`, and the nested `target` object. The description only restates the high-level purpose of the filters ("Use the optional filters to narrow the result") without adding syntax or interaction semantics, so it does not meaningfully exceed the schema baseline.

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?

States a specific verb and resource ("Return a curated font catalog") plus the exact entry fields returned, so the agent knows the payload shape before calling. It explicitly separates itself from `watchface_get_fonts_local` (on-device subset) and from the visual guide resource, which are the closest 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?

Gives explicit when-to-use routing: read `divoom://font/guide` first for visual style, cross-check with `watchface_get_fonts_local` before committing a font id to a real device, and query hardware/capabilities first for AstroToo. It also names the exclusion (legacy 800x1280 examples apply only to TimesFrame).

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