Skip to main content
Glama
cyanheads

pixoo-mcp-server

by cyanheads
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Local

pixoo_overlay_text

pixoo_overlay_text
Idempotent

Set or clear persistent scrolling text overlays on a Pixoo LED display. Use device fonts and 20 slots to keep tickers visible across channel switches.

Instructions

Set or clear a device-native scrolling text overlay. Use mode "set" to add or update an overlay on a slot (0–19); use mode "clear" to remove it. Overlays use device-rendered fonts (115 font IDs, 0–114) and persist across channel switches until explicitly cleared with mode "clear". Not previewable — rendering happens on-device. Best for persistent tickers over pushed scenes; for styled, previewable text use pixoo_display_text instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoX start position on display (default: 0).
yNoY start position on display (default: 0).
idYesOverlay slot ID (0–19). Each ID is an independent overlay layer.
fontNoDevice font ID (0–114). 0 = default, 18 = arrows, 20 = °C/°F. Device-rendered; no preview.
modeYesset = add/update overlay; clear = remove it.
textNoText to display (required for mode=set).
alignNoText alignment (default: left).left
colorNoText color as CSS hex color (default: white).#ffffff
speedNoScroll speed (0–100, device units; default: 50).
widthNoText region width in pixels (optional; defaults to display width).
directionNoScroll direction (default: left).left

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoThe overlay slot ID (0–19) that was operated on.
modeNoOperation performed: "set" (overlay added/updated) or "clear" (overlay removed).
errorNoPresent when the call failed. Absent on success.
acknowledgedNoTrue when the device confirmed the overlay command (error_code: 0).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed6 schema fields changedv1.1.1
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedOutput schema / anyOf
      Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "acknowledged",
+      "mode",
+      "id"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]
    • addedOutput schema / properties / error
      Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode. Declared by this tool: `device_unreachable`: Device is not reachable. `device_rejected`: Device firmware rejected the command. `no_device_configured`: PIXOO_IP is not set. `invalid_color`: The color value could not be resolved. Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "device_unreachable",
+            "device_rejected",
+            "no_device_configured",
+            "invalid_color"
+          ],
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}
    • removedOutput schema / required
      Removed value: -[
-  "acknowledged",
-  "mode",
-  "id"
-]
  2. First observedv1.0.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover idempotency and non-destructiveness, so the description correctly adds behavioral context beyond them: overlays persist across channel switches, rendering happens on-device, and the feature is not previewable. This is genuinely useful invocation-relevant detail.

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

Conciseness5/5

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

The description is brief, front-loaded with the core action, and every sentence contributes: action, mode usage, persistence detail, limitation, and sibling routing. No filler or tautology.

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

Completeness5/5

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

Given 11 parameters, 2 required, and a rich input schema, the description captures the behavioral context an agent needs: mode semantics, overlay slots, persistence, and when to choose this tool versus pixoo_display_text. No meaningful selection or invocation context is missing.

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 baseline is 3; the description reinforces slot/font semantics and mode behavior, but every parameter already has a descriptive schema helper. It does not need to repeat the full parameter list.

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?

Description uses specific verbs ('Set or clear') and a specific resource ('device-native scrolling text overlay'), immediately distinguishing its function. It also names the sibling it is not — pixoo_display_text — so an agent can tell them apart without opening schemas.

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?

Describes exactly when to invoke 'set' versus 'clear', and explicitly recommends pixoo_display_text for styled, previewable text. This gives clear routing guidance for the main alternative.

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/cyanheads/pixoo-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server