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

mcp-divoom-lan

Official
by DivoomDevelop
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

watchface_disp_catalog

Retrieve TimesFrame and AstroToo watchface display-element catalogs with IDs, categories, render kinds, and data sources; filter them to select valid disp and patch entries.

Instructions

Return the selected product's disp catalog for ItemList[i].disp and ItemPatchList[i].patch.disp. TimesFrame and AstroToo use independent enums and renderer sources. AstroToo entries also report category, render kind, data source, asset requirement, authoring mode, and reference-config usage. 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 disp id is in this list.
limitNoMax entries to return (default 80, max 600).
modelNoFor offline authoring only. A connected target's hardware determines its model.
targetNoOptional per-call target override. If omitted, environment variables are used.
expectsNo'image' = only slots whose hints.likelyUsesRasterOrAssetLayer is true; 'text' = only slots whose hints.oftenUsesVectorFontForText is true.
idsOnlyNoIf true, return compact rows with identity, category, render kind, data source, asset requirement, authoring mode, and usage proof.
categoryNoAstroToo category filter, such as time, date, weather, analog, calendar, music, app_data, or component.
dataSourceNoAstroToo runtime provider filter, such as device_time, weather_service, calendar_service, or local_or_cached_media.
renderKindNoAstroToo render-kind filter: text, image, animation, analog_hand, composite, or system.
nameContainsNoCase-insensitive substring filter on the English symbol (e.g., 'WEATHER').
descriptionContainsNoCase-insensitive substring filter on the Chinese description (e.g., '日历').
usedInReferenceConfigsNoAstroToo: true returns elements proven in loaded native/server reference configurations; false returns renderer-only entries.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.3.0
    • addedInput schema / properties / category
      Added value: +{
+  "description": "AstroToo category filter, such as time, date, weather, analog, calendar, music, app_data, or component.",
+  "type": "string"
+}
    • addedInput schema / properties / dataSource
      Added value: +{
+  "description": "AstroToo runtime provider filter, such as device_time, weather_service, calendar_service, or local_or_cached_media.",
+  "type": "string"
+}
    • changedInput schema / properties / idsOnly / description
      Previous value: -"If true, return only `[{disp, name, description_zh}]` rows for a compact summary."New value: +"If true, return compact rows with identity, category, render kind, data source, asset requirement, authoring mode, and usage proof."
    • changedInput schema / properties / limit / description
      Previous value: -"Max entries to return (default 80, max 300)."New value: +"Max entries to return (default 80, max 600)."
    • addedInput schema / properties / model
      Added value: +{
+  "description": "For offline authoring only. A connected target's hardware determines its model.",
+  "enum": [
+    "timesframe",
+    "astrotoo"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / renderKind
      Added value: +{
+  "description": "AstroToo render-kind filter: text, image, animation, analog_hand, composite, or system.",
+  "type": "string"
+}
    • 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"
+}
    • addedInput schema / properties / usedInReferenceConfigs
      Added value: +{
+  "description": "AstroToo: true returns elements proven in loaded native/server reference configurations; false returns renderer-only entries.",
+  "type": "boolean"
+}
  2. First observedv0.1.6

TDQS

A3.6/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden and it adds meaningful behavior: it distinguishes TimesFrame and AstroToo enums, names AstroToo return fields, mandates a hardware/capabilities lookup first, and warns that legacy 800x1280 examples apply only to TimesFrame. It stops short of stating read-only safety or response/pagination behavior, but for a catalog query it provides solid context.

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 description is front-loaded with the core action and then adds model-specific constraints and prerequisites. It is four sentences with little filler, though the jargon and dense phrasing reduce readability slightly.

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?

The tool has 12 parameters and no output schema, so the description should do more to explain return shape and row structure. It mentions AstroToo entry fields and `idsOnly` compact rows, but does not fully describe the default output or TimesFrame return values, leaving the agent to infer the catalog response format.

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 explains all 12 parameters, including the nested target object and filter enums. The description adds some value by clarifying `model` as offline-authoring-only and by tying the catalog to `ItemList[i].disp` and `ItemPatchList[i].patch.disp`, but most parameter meaning is already in the schema.

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 states a specific verb and resource: return the selected product's `disp` catalog for `ItemList[i].disp` and `ItemPatchList[i].patch.disp`. It is clearly a catalog lookup, though the term `disp` is jargon and it does not explicitly distinguish itself from sibling catalogs such as `watchface_font_catalog` or `watchface_clock_catalog`.

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?

It gives useful context for AstroToo, instructing the agent to first query hardware/capabilities and use 480x480 resources. However, it does not state when to use this tool versus the clock/font/template catalog siblings, nor does it describe explicit exclusions or alternatives beyond the model split.

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