Skip to main content
Glama
dbonomo
by dbonomo

palette_swatch

Render a labeled grid of color swatches as a PNG to visually inspect and compare colors. Accepts hex or RGB values, with optional custom labels.

Instructions

Render a labeled grid of color swatches to a PNG for eyeballing.

Args: colors: hex strings and/or "r,g,b" triples (1..64 of them). labels: optional captions, one per color; defaults to each color's palette name (or its hex when off-palette).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
colorsYes
labelsNo
Behavior4/5

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

With no annotations, the description carries full responsibility for disclosure. It adds meaningful context by specifying that labels default to palette names, and it limits the color count to 1..64. However, it does not mention side effects like file output or error handling, which would be expected for a tool that generates a PNG.

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 front-loaded with a one-sentence summary, followed by a clean Args section. Every sentence contributes necessary information, and it is appropriately sized for a two-parameter tool.

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?

The description covers the tool's purpose, parameters, and defaults, which is sufficient for a simple rendering tool. It doesn't specify how the PNG is delivered (e.g., file path or base64) or the exact grid layout, but these are secondary details. Given the output schema is absent, the description is mostly complete but could add one line about the output channel.

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?

The schema provides no parameter descriptions, so the description fully compensates. It explains that colors accept hex strings or "r,g,b" triples with a count constraint, and it clarifies that labels are optional with a default behavior. This is exactly the kind of semantic enrichment needed.

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 clearly states a specific verb and resource: "Render a labeled grid of color swatches to a PNG for eyeballing." This distinguishes the tool from siblings like color_nearest or image_quantize by emphasizing visualization for human inspection.

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 phrase "for eyeballing" provides a clear context for when the tool is appropriate, but there is no explicit mention of alternatives or when not to use it. It lacks the explicit exclusions that would earn a 5, but the use case is well implied.

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/dbonomo/pebble-mcp'

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