Skip to main content
Glama
rhinocap

Raven MCP

by rhinocap
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Hybrid

generate_design_system

DestructiveIdempotent

Generate a complete design system with full token set from a brand color. Export to HTML, CSS variables, W3C DTCG JSON, Figma Variables, or SVG; save for reuse.

Instructions

Generate a complete, custom design system with full token set. Provide a brand color to auto-generate a harmonious palette, pick a style preset, and export as visual HTML documentation, CSS variables, W3C DTCG JSON, Figma Variables, or SVG palette card. The HTML export is a beautiful, self-contained page suitable for sharing with stakeholders. Pass save:true to store the system for reuse by id — this is how a taste-engine session's design system becomes durable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesName for the design system (e.g. 'Acme Corp', 'NightOwl')
saveNoPersist the generated token set to ~/.raven/design-systems so its id works everywhere a bundled system's does: base_system here, get_design_system, list_design_systems, and init_design_md. Refused if the id (the slugified name) collides with a bundled system. Default: false
styleNoAesthetic direction — influences spacing, radii, shadows, motion, and typography. Default: minimal
formatNoExport format: html (visual doc page), css (custom properties), dtcg (W3C JSON), figma (Figma Variables JSON), svg (color palette card), all. Default: html
dark_modeNoGenerate dark mode tokens alongside light. Default: true
base_systemNoStart from an existing system as foundation (e.g. 'stripe', 'linear'). Colors will be replaced by brand_color if provided.
brand_colorNoPrimary brand hex color (e.g. '#FF6B35'). Auto-generates a full harmonious palette using color theory.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.5.1
    • addedInput schema / properties / save
      Added value: +{
+  "description": "Persist the generated token set to ~/.raven/design-systems so its id works everywhere a bundled system's does: base_system here, get_design_system, list_design_systems, and init_design_md. Refused if the id (the slugified name) collides with a bundled system. Default: false",
+  "type": "boolean"
+}
  2. First observedv2.2.9

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already flag the tool as non-read-only and potentially destructive, so the bar is lowered. The description adds useful behavioral context: save:true writes to the design system storage, id collisions are refused, and HTML output is self-contained. This goes beyond the annotations without contradicting them.

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 three purposeful sentences: core purpose and formats, value of the HTML export, and the save/reuse decision. Information is front-loaded and no sentence is 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?

For a 7-parameter generation tool, the description covers the main decisions: the inputs to provide, the export choices, the HTML output quality, and when to persist. It does not fully describe return structures for each format, but the schema is rich and the key invocation behavior is disclosed.

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 description coverage is 100%, so the baseline is 3 even without detailed description prose. The description adds some param-level flavor, such as a brand color auto-generating a palette and save:true enabling durability, but most of the param meaning already lives in the schema.

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 uses a specific verb and resource: 'Generate a complete, custom design system with full token set.' It clearly distinguishes this creation-focused tool from retrieval-oriented siblings like get_design_system and list_design_systems, and it names the core deliverables and inputs.

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 makes the core usage scenario clear, especially around persistence: passing save:true is how a design system becomes durable and reusable by id. It does not explicitly enumerate alternatives to avoid, but it gives enough contextual guidance to select this tool over the retrieve/list siblings.

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