Skip to main content
Glama

Choose the display module

set_display
Idempotent

Switch the robot's face display module among SSD1306, SSD1331, and ST7789, adapting faces and text to each screen's resolution and colour capabilities.

Instructions

Fit a different Face Display module: "ssd1306" (0.96" 128×64 monochrome OLED, I²C; default), "ssd1331" (0.95" 96×64 colour RGB OLED, SPI) or "st7789" (1.3" 240×240 colour IPS TFT, SPI). Faces and text adapt to the resolution; colour modules show a colour per emotion. panel changes the SSD1306 glass colour. Returns read_display.

Input Schema

NameRequiredDescriptionDefault
modelNo
panelNoSSD1306 panel colour: yellow-blue (top 16 rows yellow, rest blue; the default), white, blue or yellow

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.1

TDQS

A4.1/5.0
Behavior3/5

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

Annotations only declare idempotentHint=true. The description adds useful behavior: model resolutions/interfaces, adaptation of faces and text, colour-per-emotion on colour modules, and that it returns read_display. It does not disclose prerequisites such as connection/power state or side effects of swapping modules.

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 a single dense, front-loaded sentence that starts with the action and then enumerates the options. Every clause contributes model or behavior detail without filler.

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?

With no output schema, the description usefully states that the tool returns read_display. It is complete enough to select a module and understand the display adaptation effects, though it omits operational prerequisites and side effects of switching hardware modules.

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 50%, and the undocumented model enum is fully compensated by the description, which explains each model's size, resolution, colour/monochrome type, interface, and default. The panel parameter is already described in the schema, and the description adds that it changes the SSD1306 glass colour.

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 states a specific verb and resource: fitting a different Face Display module. It enumerates all three model values, notes the default, and mentions the return sibling read_display, making the tool distinguishable from read_display and draw_display.

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?

Usage is implied by 'Fit a different Face Display module' and the default is noted, but there is no explicit when-to-use guidance versus alternatives such as read_display, draw_display, or set_module. The agent can infer the context but is not routed explicitly.

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