Brix Digital Signage

Create designs

create_creatives

Author new creatives (data-bound canvases) from scratch. This is how you BUILD templates programmatically. Each: { name, stage?:'landscape'|'portrait', backgroundUrl?, dataSourceId?, nodeId?, boxes:[…] }. A box is { kind, x, y, w, h, … } where x/y/w/h are 0–1 fractions of the stage and kind is one of text|field|list|image|shape|celebrations|event-board|signage|group|slot. Shapes use { shape:'rect'|'circle'|'line'|'triangle', fill, stroke, strokeWidth, cornerRadius }; text uses { text, color, fontWeight, align, fontSize? }; field/list bind via { field:'dot.path' }; image uses { url }; slot is a transparent hole the screen fills with real content, like a layout zone — { slot: { kind:'media'|'playlist'|'app', id, name } } naming a file / playlist / app in THIS workspace (or slot:null for an empty hole the customer fills later; borderRadius clips what plays there); signage is a full Signage Template Engine block — { signage: { archetype, style, mode, industry, orientation, content, anim } } — rendered 1:1 (layout + animations), usually one full-bleed box (x:0,y:0,w:1,h:1). Boxes are validated + clamped server-side; an invalid box rejects the whole call. Max 100 creatives per call. Designs also pass a quality gate (the Brix template standard): REJECTED with named findings when text pins under 24px (1920w scale), an authored contrast pair computes <3:1, or one layer fully hides another; WARNED as structured diagnostics for busy layouts (>36 content layers), >5 font sizes, >2 font families, hand-frozen list rows that should be ONE list box, static clock/date copy instead of {{now.*}} tokens, and competing loop animations. Treat warnings as defects: fix and re-emit. Creating a design shows it nowhere; put it on screens with assign_content or cast_content. For a one-off text announcement use quick_post.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`creatives`	Yes	Creatives to create, max 100 per call. One invalid box rejects the whole call.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedOct 17, 2026

addedInput schema / properties / creatives / description

Added value: +"Creatives to create, max 100 per call. One invalid box rejects the whole call."

addedInput schema / properties / creatives / items / properties / boxes / description

Added value: +"The layers of the design; see the tool description for each kind's extra fields."

addedInput schema / properties / creatives / items / properties / boxes / items / properties / h / description
```
Added value: +"Height, as a fraction of the stage height."
```
addedInput schema / properties / creatives / items / properties / boxes / items / properties / kind / description
```
Added value: +"Layer type; decides which extra fields apply."
```

changedInput schema / properties / creatives / items / properties / boxes / items / properties / slot / description

Previous value: -"kind:'slot' only — the file / playlist / app this hole plays (ids from list_media / list_playlists / list_app_instances in this workspace). null = an empty hole the customer fills in the editor."New value: +"kind:'slot' only — the file / playlist / app this hole plays (ids from search_media or list_items in this workspace). null = an empty hole the customer fills in the editor."

changedInput schema / properties / creatives / items / properties / boxes / items / properties / slot / oneOf

Previous value: -[
-  {
-    "type": "null"
-  },
-  {
-    "properties": {
-      "id": {
-        "type": "string"
-      },
-      "kind": {
-        "enum": [
-          "media",
-          "playlist",
-          "app"
-        ],
-        "type": "string"
-      },
-      "name": {
-        "description": "Display label shown in the editor; optional.",
-        "type": "string"
-      }
-    },
-    "required": [
-      "kind",
-      "id"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "type": "null"
+  },
+  {
+    "properties": {
+      "id": {
+        "description": "Id of that file, playlist or app in this workspace.",
+        "type": "string"
+      },
+      "kind": {
+        "description": "What fills the hole: a media file, a playlist or an app.",
+        "enum": [
+          "media",
+          "playlist",
+          "app"
+        ],
+        "type": "string"
+      },
+      "name": {
+        "description": "Display label shown in the editor; optional.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "kind",
+      "id"
+    ],
+    "type": "object"
+  }
+]

addedInput schema / properties / creatives / items / properties / boxes / items / properties / w / description
```
Added value: +"Width, as a fraction of the stage width."
```
addedInput schema / properties / creatives / items / properties / boxes / items / properties / x / description
```
Added value: +"Left edge, as a fraction of the stage width (0 = left, 1 = right)."
```
addedInput schema / properties / creatives / items / properties / boxes / items / properties / y / description
```
Added value: +"Top edge, as a fraction of the stage height (0 = top, 1 = bottom)."
```
addedInput schema / properties / creatives / items / properties / name / description
```
Added value: +"Creative display name."
```
addedInput schema / properties / creatives / items / properties / stage / description
```
Added value: +"Canvas orientation; default landscape."
```

First observedOct 17, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations (which only declare non-read-only, non-destructive, closed-world) by disclosing server-side validation/clamping, whole-call rejection on an invalid box, a 100-creative cap, and the full quality-gate behavior including specific REJECT and WARN conditions. This is exactly the operational context an agent needs before invoking.

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?

Purpose and alternatives are front-loaded and almost every sentence carries information, but the box-kind documentation is delivered as one dense run-on paragraph rather than clearly delimited, which slows parsing for a payload this complex.

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 complex write tool with an output schema already present, the description covers creation semantics, validation/failure modes, the quality gate, limits, and the follow-up tooling to make the design visible. Nothing necessary for correct invocation is missing.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds meaning the schema does not: the per-kind extra fields for text, field, list, image, shape, signage, and slot layers, plus the 0–1 fractional coordinate semantics and the 'slot:null = empty hole' convention. It substantially exceeds the schema on the most consequential nested payload.

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 ('Author new creatives (data-bound canvases) from scratch') and frames the tool's role as the programmatic template-building path. It explicitly distinguishes itself from assign_content, cast_content, and quick_post, so an agent can route without opening a schema.

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 ('This is how you BUILD templates programmatically') and what happens after ('Creating a design shows it nowhere; put it on screens with assign_content or cast_content'). It also names a direct alternative with its triggering condition ('For a one-off text announcement use quick_post').

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

All Brix Digital Signage tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?