This server provides deterministic design style intelligence for AI content generation pipelines, offering two core tools:
recommend_style: Get a data-driven style recommendation by providing a campaign objective (e.g., product_launch, brand_awareness), target demographic (e.g., gen_z, executives), and optional brand description and season. The server scores all 30 built-in styles using deterministic fuzzy matching and returns the best match with reasoning and ranked alternatives — no AI inference involved.
get_style: Fetch structured design tokens for any of the 30 curated styles by providing a style slug (e.g., cyberpunk, neo-brutalism, luxury). Returned data includes:
Style name and description
Color palette
Typography rules
Mood tokens
Visual directives
Negative prompts (for image/video generation pipelines)
Available Styles (30): academia, art-deco, bauhaus, bold-typography, botanical, claymorphism, cyberpunk, enterprise, flat-design, industrial, kinetic, luxury, material, maximalism, minimal-dark, modern-dark, monochrome, neo-brutalism, neumorphism, newsprint, organic, playful-geometric, professional, retro, saas, sketch, swiss-minimalist, terminal, vaporwave, web3
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Design Style MCP Server recommend a style for a streetwear brand targeting Gen Z for a product launch"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides design style intelligence for AI content generation. Ships with 30 curated design styles — each with color palettes, typography, mood tokens, visual directives, and negative prompts ready for image/video generation pipelines.
No AI inference — pure deterministic scoring against style characteristics.
Tool | Description |
| Deterministic style recommendation based on brand context, campaign objective, target demographic, and season. Returns a top match with scoring reasoning and ranked alternatives. |
| Retrieve structured design tokens for a given style slug: name, description, color palette, typography, mood, visual directives, and negative prompt sections. |
academia, art-deco, bauhaus, bold-typography, botanical, claymorphism, cyberpunk, enterprise, flat-design, industrial, kinetic, luxury, material, maximalism, minimal-dark, modern-dark, monochrome, neo-brutalism, neumorphism, newsprint, organic, playful-geometric, professional, retro, saas, sketch, swiss-minimalist, terminal, vaporwave, web3
Each style includes a full prompt file with design philosophy, color system, typography rules, visual directives, and negative prompts.
Related MCP server: the-designer
Node.js 22.14+
Published package: @luminarylane/design-style-mcp-server on npm
Run without a global install:
npx --yes @luminarylane/design-style-mcp-serverTo run from source:
git clone https://github.com/luminarylane/design-style-mcp-server.git
cd design-style-mcp-server
npm install
npm run build# Development
npm run dev
# Production
npm startAdd to your claude_desktop_config.json:
{
"mcpServers": {
"design-style": {
"command": "npx",
"args": ["--yes", "@luminarylane/design-style-mcp-server"]
}
}
}recommend_styleGiven a brand description, campaign objective, target demographic, and optional season, the server scores all 30 styles against their characteristics (objectives, demographics, industries, moods, seasonal fit) and returns the top match with alternatives.
Input: { objective: "product_launch", demographic: "gen_z", brand: "streetwear" }
Output: { style: "neo-brutalism", reasoning: "...", alternatives: [...] }get_styleGiven a style slug, returns structured tokens extracted from the style's prompt file:
Input: { style: "cyberpunk" }
Output: { name, description, colors, typography, mood, promptAdditions, negativePrompt, reference }Env Var | Default | Description |
|
| Override path to the design-styles data directory |
Transport: stdio (standard MCP protocol)
Data: 30 style prompt files + descriptions index (plain text, bundled)
Scoring: Deterministic fuzzy matching — no AI inference, no network calls
Caching: Prompt files are cached in-memory after first read
Dependencies: Only @modelcontextprotocol/sdk and zod
# Development server (auto-reload)
npm run dev
# Type check
npx tsc --noEmit
# Build
npm run buildAdd the slug to DESIGN_STYLE_SLUGS in src/styles.ts
Add characteristics (objectives, demographics, industries, moods) to STYLE_CHARACTERISTICS
Add a description line to design-styles/descriptions.txt
Create a prompt file at design-styles/prompts/{slug}.txt
The design-style prompt collection was inspired by and initially sourced from designprompts.dev. This project is an independent MCP server and is not affiliated with or endorsed by designprompts.dev.
Retrieve structured design style tokens for AI content generation. Returns name, description, color palette, typography, mood, visual directives, and negative prompt sections extracted from the style's prompt file. Valid slugs: academia, art-deco, bauhaus, bold-typography, botanical, claymorphism, cyberpunk, enterprise, flat-design, industrial, kinetic, luxury, material, maximalism, minimal-dark, modern-dark, monochrome, neo-brutalism, neumorphism, newsprint, organic, playful-geometric, professional, retro, saas, sketch, swiss-minimalist, terminal, vaporwave, web3
| Name | Required | Description | Default |
|---|---|---|---|
| style | Yes | Design style slug (e.g., 'professional', 'saas', 'neo-brutalism'). Must be one of the valid slugs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool as read-only (retrieve) and lists the return content. No side effects or auth requirements are mentioned, but for a simple retrieval, this is transparent enough. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each earning its place: first states purpose and return content, second lists valid slugs. No unnecessary words, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter retrieval tool with no output schema, the description is complete: it explains what the tool does, what it returns (including specific sections), and the valid inputs. No gaps remain for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a descriptive parameter. The description adds the list of 30 valid slugs beyond the schema's brief example, providing concrete enumeration that helps the agent select valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves structured design style tokens for AI content generation, lists the specific sections returned (name, description, color palette, typography, mood, visual directives, negative prompt), and distinguishes from the sibling 'recommend_style' by focusing on retrieving known style tokens rather than recommending.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a specific style's full definition is needed, and lists 30 valid slugs. While no explicit when-not-to-use or alternative is given, the context of sibling 'recommend_style' suggests that tool is for recommendations. Clear context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend a design style based on brand context, campaign objective, and target demographic. Returns a top match with reasoning and alternatives. No AI inference — uses deterministic scoring against style characteristics.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | Brand description or keywords (e.g., 'luxury wellness spa targeting affluent women') | |
| season | No | Season for seasonal relevance (e.g., 'spring', 'summer') | |
| objective | Yes | Campaign objective (e.g., 'product_launch', 'brand_awareness', 'lead_generation', 'engagement') | |
| demographic | Yes | Target demographic (e.g., 'tech_savvy', 'gen_z', 'executives', 'families') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'No AI inference — uses deterministic scoring against style characteristics', which clarifies the computational behavior and lack of AI stochasticity. It does not detail auth needs or rate limits but is adequate for a read-only recommendation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the purpose, second adds critical behavioral info (deterministic, returns reasoning and alternatives). No wasted words, front-loaded with core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (2 required), no output schema, and no annotations, the description adequately explains inputs and output (top match with reasoning and alternatives). It could elaborate on the return structure or examples, but is sufficiently complete for an agent to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description does not add meaning beyond what the schema already provides. The examples in the description are similar to the schema's description, so no additional value is added. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'recommends a design style' based on brand, objective, and demographic. It also distinguishes itself from the sibling tool 'get_style' by specifying it returns a top match with reasoning and alternatives, and clarifies it uses deterministic scoring versus AI inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for recommending a style based on inputs, but does not explicitly state when to use it versus alternatives like 'get_style'. There is no guidance on when not to use it or specific prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_stylerecommend_styleBoth tools have clearly distinct purposes: get_style retrieves details for a known style, recommend_style suggests a style based on context. No overlap.
Both tool names follow the verb_noun pattern (get_style, recommend_style) consistently, making them predictable.
With only 2 tools, the server is minimal but still covers the core functionality for its narrow domain. A list tool would be useful but not mandatory.
Covers retrieval and recommendation, but lacks a tool to list all available style slugs programmatically, which is a notable gap since get_style requires a valid slug.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A design-style library for AI agents: search real styles, fetch a ready-to-apply design spec.
Curated design references for AI — real CSS values, typography specs, and color palettes.
Build and manage your design system with AI: tokens, themes, components, icons, Figma and code.
Generate design systems: OKLCH color palettes, fluid type scales, spacing, shape and icon tokens.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/luminarylane/design-style-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
