blipboard

Push Scenes Tool

push-scenes-tool

Push text scenes to a Blipboard board. Scenes replace your source's previous scenes by default and rotate as a playlist on the display. Requires the board's secret pushToken.

Input Schema

TableJSON Schema

Name	Required	Description
`scenes`	Yes	Scenes to display, each an object: {"lines": ["ROW 1 TEXT", "..."], "durationMs"?: 1000-300000, "ttlSeconds"?: seconds until the scene disappears, "expiresAt"?: ISO 8601, "tileColors"?: [{"row","column","color"}], "animations"?: [{"row", "column", "frames": ["🟩","⬛"], "intervalMs"?: 200-10000}]}. lines are placed 1:1 (line N = row N, char M = column M, no centering). Palette emojis ⬜🟥🟧🟨🟩🟦🟪 render as colored tiles; ALL other emojis are supported and display literally as characters (one emoji = one tile), e.g. "HELLO 🎉". animations make a single tile flip between 2-8 frames while the scene is shown — e.g. a blinking terminal cursor {"row":0,"column":21,"frames":["🟩","⬛"],"intervalMs":1000} or winking eyes with emoji frames.
`source`	Yes	Lowercase identifier of the pusher, e.g. "claude". Each source owns its scenes; pushing replaces only this source's scenes.
`replace`	No	true (default) replaces this source's previous scenes, false appends.
`boardUrl`	Yes	The board displayUrl returned by create-board, or its bare 21-character display token.
`pushToken`	Yes	The board's secret push token.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description fully carries the burden of transparency. It discloses key behaviors: scenes replace previous scenes by default, rotate as a playlist, require a pushToken, and the source identifier controls ownership. It lacks details on error handling or idempotency but is otherwise thorough.

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 highly concise: two sentences for purpose and general behavior, followed by one detailed paragraph for the scenes parameter. Every sentence adds necessary information without redundancy or fluff. Front-loaded with the most critical info.

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?

Given the tool's complexity (5 params, nested scenes array) and no output schema, the description covers the core functionality, token requirement, and scene structure. It is missing return value details and error handling, but the schema descriptions also aid understanding, making it fairly complete.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds significant semantic value beyond the schema, such as explaining scene replacement/append behavior, rotation as a playlist, and clarifying the scene object structure with examples. This enriches the agent's understanding.

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 starts with a specific verb-resource pair ('Push text scenes to a Blipboard board') and clearly differentiates from sibling tools, which are all about board CRUD operations. It immediately establishes the tool's unique function of pushing content to a board.

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 explains default behavior (replace vs. append) and rotation as a playlist, providing clear context. However, it does not explicitly state when not to use this tool or suggest alternatives, which is acceptable given the distinct nature of sibling tools.

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

All blipboard tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool targets a distinct operation on Blipboard boards: create, delete, push scenes, read, and update. No overlap in functionality, agents can easily differentiate.

Naming Consistency5/5

All tools follow a consistent 'verb-board-tool' pattern (e.g., create-board-tool, push-scenes-tool), with verbs in imperative form and clear noun references.

Tool Count5/5

With 5 tools, the server covers the core actions needed for managing split-flap display boards without unnecessary duplication or missing essentials.

Completeness5/5

The tool set covers the full lifecycle: create board, read its state, push scenes, update style, and delete. No obvious gaps for the stated purpose.

Resources

Need Help?