pixoo-mcp-server

Overview Schema Source Related Servers Discussions Admin

pixoo_design_brief

pixoo_design_brief

Read-only

Get design guidance and live device context for text, scenes, dashboards, animations, pixel art, or troubleshooting before authoring or fixing a Pixoo display.

Instructions

Return craft guidance and live device context for a design topic. Covers legibility rules, palette discipline, layout zones, animation budget, and pre-filled next-tool suggestions based on current device state. The orientation tool to run before authoring a scene, dashboard, or animation — or when troubleshooting display issues.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`topic`	Yes	Design topic: text (styled text guidance), scene (composition + layout zones), dashboard (widgets + metrics), animation (motion budget + effects), pixel-art (bitmap + sprite guidance), troubleshooting (device + display issues).

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`topic`	No	The topic that was requested.
`craftGuidance`	No	Markdown-formatted craft rules: legibility floors, palette discipline, layout zones, and technique guidance specific to the topic.
`deviceContext`	No	Live device state snapshot at the time of the request.
`iconCategories`	No	Built-in icon names grouped by category (weather, arrows, status, media). Use names in pixoo_compose_scene icon elements.
`availableThemes`	No	Available named scene themes (e.g. "midnight", "ember"). Use in background.theme or pixoo_display_text theme param.
`nextToolSuggestions`	No	Suggested next steps based on topic and device state.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv1.2.0Sep 25, 2026

changedOutput schema / properties / nextToolSuggestions / items / description

Previous value: -"A suggested next-step tool with rationale and optional pre-filled args."New value: +"A recommended follow-up call with its arguments pre-filled."

addedOutput schema / properties / nextToolSuggestions / items / properties / args

Added value: +{
+  "additionalProperties": {},
+  "description": "Pre-filled arguments for the call; {} when the tool needs none.",
+  "properties": {},
+  "type": "object"
+}

removedOutput schema / properties / nextToolSuggestions / items / properties / rationale

Removed value: -{
-  "description": "Why this tool is relevant given current state.",
-  "type": "string"
-}

addedOutput schema / properties / nextToolSuggestions / items / properties / reason

Added value: +{
+  "description": "Why this step is recommended given the current device state.",
+  "type": "string"
+}

removedOutput schema / properties / nextToolSuggestions / items / properties / suggestedArgs

Removed value: -{
-  "additionalProperties": {},
-  "description": "Pre-filled argument suggestions as a key-value object.",
-  "properties": {},
-  "type": "object"
-}

removedOutput schema / properties / nextToolSuggestions / items / properties / tool

Removed value: -{
-  "description": "Tool name to try next.",
-  "type": "string"
-}

addedOutput schema / properties / nextToolSuggestions / items / properties / toolName
```
Added value: +{
+  "description": "Tool to call next.",
+  "type": "string"
+}
```

changedOutput schema / properties / nextToolSuggestions / items / required

Previous value: -[
-  "tool",
-  "rationale"
-]New value: +[
+  "toolName",
+  "reason",
+  "args"
+]

Changed6 schema fields changedv1.1.1Aug 24, 2026

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": [
+      "topic",
+      "craftGuidance",
+      "deviceContext",
+      "nextToolSuggestions",
+      "availableThemes",
+      "iconCategories"
+    ]
+  },
+  {
+    "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.",
+          "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: -[
-  "topic",
-  "craftGuidance",
-  "deviceContext",
-  "nextToolSuggestions",
-  "availableThemes",
-  "iconCategories"
-]

First observedv1.0.0Jun 17, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=true, so the description carries the burden of explaining behavior. It adds useful context by mentioning 'live device context' and 'pre-filled next-tool suggestions based on current device state,' clarifying that this is a read-only advisory tool rather than a device-mutating operation.

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?

Two sentences with no filler. The first sentence states the core value and content scope; the second explains the operational context. All information is front-loaded and directly useful to an agent.

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?

For a single-parameter advisory tool with a fully documented schema, an output schema, and a readOnly annotation, the description fully covers what the tool does, what it covers, and when to use it. No critical gaps remain.

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?

The input schema fully documents the single 'topic' parameter, including an enum of all allowed values and descriptions for each. The description adds little beyond the schema, so baseline 3 is appropriate since the schema already does the heavy lifting.

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 names a specific verb and resource: 'Return craft guidance and live device context for a design topic.' It also enumerates the covered areas (legibility rules, palette discipline, layout zones, animation budget) and positions itself as an orientation tool versus the sibling action tools, making its role distinct.

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

Usage Guidelines4/5

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

The description explicitly states when to run the tool: 'before authoring a scene, dashboard, or animation — or when troubleshooting display issues.' This gives clear context for selection, though it does not explicitly name sibling alternatives or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server