Skip to main content
Glama

standby-design-mcp

by io.github.KarstenKreh

Generate color palette

generate_color_palette
Read-only

Generate a perceptually uniform OKLCH color palette from a brand color: 18-step scales for brand/surface/error/accents, semantic tokens (shadcn/ui compatible), light+dark modes. Returns a shareable standby.design/system URL and a compact summary. Always give that URL to the user — the link is the deliverable; it opens the live system in the browser. Use export_design_system for full CSS/Tailwind output.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoExisting standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing settings from other tools are preserved. Omit to start fresh from defaults.
modeNo"balanced": step 500 is always the perceptual midpoint (even light/dark distribution). "exact": step 500 keeps the input color's lightness.
accentsNoUp to 3 additional named accent colors. Replaces the existing accent list when provided; pass [] to remove all accents. Default: Success/Warning/Info, auto-derived.
brandHexNoBrand color as 6-digit hex, e.g. "#335A7F". The palette midpoint is derived from this.
brandPinNoPin the primary token to the exact input hex instead of the palette step.
errorPinNo
themeNameNoName of the design system (appears in exports and page title).
bgColorHexNoSurface tint color as hex, or "auto" to derive from the brand color (default).
brandInvertNoFor pinned brand: mirror lightness in dark mode (e.g. black buttons in light mode, white in dark).
chromaScaleNoSurface saturation 0–1 (0 = grey surfaces, 1 = vibrant). Default 0.25.
errorInvertNo
errorColorHexNoError/destructive color as hex, or "auto" to derive from the brand hue (default).
fgContrastModeNoText color strategy on colored backgrounds.

TDQS

A4/5.0
Behavior3/5

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

Annotations declare readOnlyHint=true, and the description does not contradict this. Description adds that the tool generates a URL and summary, but does not elaborate on side effects, auth needs, or rate limits. Since annotations already cover safety, the description provides minimal additional behavioral context.

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?

Description is three concise sentences, front-loaded with the primary function. Every sentence adds essential information without redundancy, making it efficient for an AI agent to parse quickly.

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?

Despite 13 parameters and no output schema, the description clearly explains the return value (URL and summary) and its significance. The rich schema covers parameter specifics, so the description adequately complements it for complete context.

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?

Schema coverage is 85%, so the schema already documents most parameters. Description adds no extra parameter-level detail beyond what is in the schema. Baseline score of 3 is appropriate as the description does not meaningfully enhance parameter 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?

Description clearly states it generates a perceptually uniform OKLCH color palette from a brand color, specifying outputs (18-step scales, semantic tokens, URL). Distinguishes from sibling 'export_design_system' for full CSS/Tailwind, making the tool's specific purpose evident.

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?

Explicitly instructs to always give the URL to the user as the deliverable, and mentions using 'export_design_system' for full output. Provides clear context for when to use this tool versus alternatives, though lacks explicit 'when not to use' scenarios.

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

All standby-design-mcp toolsInspect
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.3/5.0
Disambiguation5/5

Each tool targets a distinct design token category (color, icon, shape, space, type) or a distinct operation (export, get, list fonts). There is no overlap in purpose or output format.

Naming Consistency5/5

Generation tools consistently use generate_*_tokens except for generate_type_scale and generate_color_palette which still follow the generate_ verb. Utility tools use clear action verbs (export, get, list) with all lowercase snake_case naming.

Tool Count5/5

Eight tools provide a well-scoped set for design system token generation and retrieval. Each tool earns its place without redundancy or unnecessary bloat.

Completeness4/5

The set covers the main design system pillars (color, typography, spacing, shape, icons) plus export and retrieval workflows. Minor gaps like a direct 'update' or 'delete' tool are unnecessary for the generative use case.

Resources