Skip to main content
Glama
YonasValentin

Design Inspiration MCP Server

by YonasValentin
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

design-inspiration

MCP server that searches Dribbble, Behance, Awwwards, Mobbin, and Pinterest for UI design inspiration. Built for Claude Code but works with any MCP client.

Uses the Serper API (Google search) with site: filters to scope results to design platforms only. Can also extract actual design tokens (colors, fonts, spacing) from any live website via headless browser.

Find inspiration, then extract exact tokens from sites you like.

Why

I wanted Claude to pull design references while building UI — look at real Dribbble shots, find color palettes, browse layout patterns — without leaving the terminal. The existing options either required Playwright (heavy) or didn't return image URLs I could actually download and view.

The search side wraps Serper's image and web search endpoints with pre-configured site filters. Simple.

The token extraction side came from a different itch: I'd find a site I liked on Dribbble, open it, and then manually eyedrop colors and inspect fonts. Now I just point design_extract_tokens at the URL and get the exact values back.

Related MCP server: Mobbin MCP Server

Tools

design_search_images — Image search across design platforms. Returns image URLs, dimensions, source links. Good for finding visual references for a specific UI pattern.

design_search_references — Web search scoped to design sites. Returns article titles, snippets, links. Better for finding case studies, design system docs, or pattern explanations.

design_search_styles — Searches for a specific aesthetic direction (color palette, typography, layout, animation). Runs both image and web search in parallel, returns combined results.

design_extract_tokens — Extracts design tokens from a live website. Point it at any URL and get back colors, typography, spacing, border radii, and shadows. Supports dark_mode and mobile flags. Requires dembrandt installed globally (npm install -g dembrandt).

The three search tools accept a sites parameter to filter to specific platforms, and a num parameter to control result count.

Setup

You need a Serper API key for the search tools. Free tier gives you 2,500 searches with no credit card.

  1. Sign up at serper.dev

  2. Copy your API key

For token extraction, install dembrandt globally:

npm install -g dembrandt

Claude Code

claude mcp add design-inspiration -e SERPER_API_KEY=your-key-here -- node /path/to/design-inspiration-mcp-server/dist/index.js

Any MCP client (stdio)

{
  "design-inspiration": {
    "type": "stdio",
    "command": "node",
    "args": ["/path/to/design-inspiration-mcp-server/dist/index.js"],
    "env": {
      "SERPER_API_KEY": "your-key-here"
    }
  }
}

Build from source

git clone https://github.com/YonasValentin/design-inspiration-mcp-server.git
cd design-inspiration-mcp-server
npm install
npm run build

How it actually works

Each tool builds a search query by appending site:dribbble.com OR site:behance.net OR ... to whatever you searched for. Then it hits Serper's /images or /search endpoint and formats the response.

The design_search_styles tool runs both endpoints in parallel (Promise.all) to get images and articles for the same query.

design_extract_tokens shells out to dembrandt (via child_process.execFile) with --json-only, parses the JSON output, and formats it into markdown + structured data. 60-second timeout. No extra npm dependencies — dembrandt runs as a global CLI and child_process is built-in.

Results are returned as both markdown (for display) and structured JSON (for programmatic use). Responses get truncated at 25,000 characters to avoid flooding the context window.

Usage tips

Search for specific UI patterns, not generic terms:

# good
"fintech dashboard dark mode"
"mobile onboarding flow card swipe"
"saas pricing page comparison table"

# too vague
"nice website"
"good design"

You can download the returned image URLs and have Claude view them directly:

curl -sL "https://cdn.dribbble.com/..." -o /tmp/reference.jpg

Then ask Claude to read the image file — it can see and describe the design.

License

MIT

Available Tools

4 tools
design_extract_tokensExtract design tokens from websiteA
Read-onlyIdempotent

Extract actual design tokens (colors, typography, spacing, borders, shadows) from a live website using headless browser. Give it any URL and get back the exact values used. Pairs well with the search tools — find inspiration, then extract tokens from sites you like.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesWebsite URL to extract design tokens from. Examples: "https://stripe.com", "https://linear.app"
dark_modeNoExtract colors from dark mode variant
mobileNoExtract from mobile viewport (375px)

TDQS

A4.4/5.0
Behavior4/5

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

The description adds valuable behavioral context beyond what annotations provide: it specifies the extraction method ('using headless browser'), indicates it works on 'live websites,' and mentions the tool's purpose in a design workflow. While annotations already cover safety (readOnlyHint=true, destructiveHint=false) and reliability (idempotentHint=true, openWorldHint=true), the description enhances understanding of how the tool operates in practice.

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 efficiently structured in two sentences: the first explains the core functionality, and the second provides usage context and integration with sibling tools. Every phrase adds value without redundancy, making it easy to parse and understand 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?

Given the tool's moderate complexity (3 parameters, no output schema) and rich annotations (covering safety and reliability), the description provides sufficient context for effective use. It explains what the tool does, how it fits with other tools, and its practical application. The main gap is the lack of output format details, but this is partially mitigated by the clear purpose statement.

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?

With 100% schema description coverage, the input schema already fully documents all three parameters (url, dark_mode, mobile). The description doesn't add any parameter-specific details beyond what's in the schema, so it meets the baseline expectation without providing extra semantic value.

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 the specific action ('Extract actual design tokens'), the resource ('from a live website'), and the method ('using headless browser'). It explicitly lists the types of tokens extracted (colors, typography, spacing, borders, shadows) and distinguishes itself from sibling search tools by focusing on extraction rather than discovery.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('Give it any URL and get back the exact values used') and how it complements sibling tools ('Pairs well with the search tools — find inspiration, then extract tokens from sites you like'). This clearly differentiates it from the search-focused siblings (design_search_images, design_search_references, design_search_styles).

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

design_search_imagesSearch design imagesA
Read-onlyIdempotent

Image search across Dribbble, Behance, Awwwards, Mobbin, and Pinterest. Returns image URLs, dimensions, and source links. Use specific UI terms ("fintech dashboard dark mode") over vague ones ("nice design").

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesUI design search query. Examples: "dashboard dark mode", "mobile onboarding flow", "saas pricing page"
sitesNoFilter to specific design sites. Empty array searches all sites. Options: dribbble, behance, awwwards, mobbin, pinterest
numNoNumber of image results to return (1-40, default: 10)

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and behavior. The description adds context about the search scope (five specific sites) and result format (URLs, dimensions, source links), which is useful but doesn't provide rich behavioral details like rate limits or authentication needs. No contradiction with annotations.

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 two sentences, front-loaded with the core functionality and followed by usage guidance. Every sentence earns its place with no wasted words, making it efficient and easy to parse.

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?

Given the tool's moderate complexity (3 parameters, no output schema), the description is mostly complete. It covers purpose, usage, and result format, but lacks details on error handling or pagination. With annotations providing safety context, it's sufficient but could be slightly enhanced for full completeness.

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%, with each parameter well-documented in the schema. The description adds minimal value beyond the schema by implying the query should be UI-focused and specific, but doesn't explain parameter semantics in detail. Baseline 3 is appropriate given high schema coverage.

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 the tool searches for images across five specific design platforms (Dribbble, Behance, Awwwards, Mobbin, Pinterest) and returns specific data (image URLs, dimensions, source links). It distinguishes itself from sibling tools like 'design_search_references' and 'design_search_styles' by focusing on image search rather than references or styles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool by recommending specific UI terms (e.g., 'fintech dashboard dark mode') over vague ones (e.g., 'nice design'). It doesn't mention alternatives, but the context of sibling tools (design_search_references, design_search_styles) implies differentiation, and the guidance is clear for this specific use case.

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

design_search_referencesSearch design referencesA
Read-onlyIdempotent

Web search scoped to design platforms. Returns article titles, snippets, and links. Better than image search when you want case studies, write-ups, or design system documentation.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesUI design search query. Examples: "best dashboard designs 2025", "mobile navigation patterns"
sitesNoFilter to specific design sites. Empty array searches all sites.
numNoNumber of results to return (1-20, default: 10)

TDQS

A4.4/5.0
Behavior4/5

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

Annotations cover read-only, open-world, idempotent, and non-destructive traits, so the description doesn't need to repeat these. It adds valuable context by specifying the search scope ('design platforms') and the types of content returned ('article titles, snippets, and links'), which helps the agent understand the tool's behavior beyond the annotations. No contradictions with annotations are present.

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 the core purpose in the first sentence, followed by a clarifying second sentence on usage guidelines. Both sentences are essential, with no wasted words, making it efficient and well-structured for quick comprehension.

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?

Given the tool's moderate complexity (3 parameters, 100% schema coverage, no output schema), the description is largely complete. It covers purpose, usage guidelines, and behavioral context, though it could slightly enhance completeness by mentioning the lack of output schema or potential limitations like result freshness. However, it provides sufficient context for effective use.

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%, with each parameter well-documented in the schema (e.g., query examples, site options, result limits). The description does not add significant semantic details beyond the schema, such as explaining parameter interactions or edge cases. Baseline score of 3 is appropriate as the schema carries the full burden.

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 the tool performs a 'web search scoped to design platforms' and specifies it 'returns article titles, snippets, and links.' It distinguishes from sibling tools like 'design_search_images' by emphasizing it's 'better than image search when you want case studies, write-ups, or design system documentation,' making the purpose specific and differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool versus alternatives: it states it's 'better than image search when you want case studies, write-ups, or design system documentation,' which implicitly contrasts with sibling tools like 'design_search_images' and 'design_search_styles.' This gives clear context for selection among similar tools.

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

design_search_stylesSearch design stylesA
Read-onlyIdempotent

Search for a specific aesthetic direction — color palettes, typography, layouts, or animation references. Runs image and web search in parallel and returns combined results.

ParametersJSON Schema
NameRequiredDescriptionDefault
styleYesDesign style to search for. Examples: "minimalist dark theme", "brutalist web design", "glassmorphism"
typeNoType of style inspiration to search forgeneral
numNoNumber of results (1-20, default: 10)

TDQS

A4/5.0
Behavior3/5

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

Annotations already cover key behavioral traits (read-only, open-world, idempotent, non-destructive). The description adds useful context about the tool's parallel search behavior ('Runs image and web search in parallel and returns combined results'), which is not captured in annotations. However, it does not disclose other behavioral aspects like rate limits, authentication needs, or result format details.

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 appropriately sized and front-loaded with the core purpose in the first sentence, followed by behavioral details. Every sentence earns its place by adding value without redundancy, making it efficient and well-structured.

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?

Given the tool's moderate complexity, rich annotations, and 100% schema coverage, the description is mostly complete. It covers purpose and unique behavioral traits. However, without an output schema, it does not explain return values (e.g., result format or structure), leaving a minor gap in completeness.

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 schema fully documents all parameters. The description does not add any additional meaning or semantics beyond what the schema provides (e.g., it doesn't explain parameter interactions or provide extra examples). Baseline score of 3 is appropriate when the schema does the heavy lifting.

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 the tool's purpose with specific verbs ('Search for a specific aesthetic direction') and resources ('color palettes, typography, layouts, or animation references'), and distinguishes it from siblings by mentioning it runs 'image and web search in parallel and returns combined results'—unlike design_search_images which likely only searches images.

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 provides clear context for when to use this tool ('Search for a specific aesthetic direction'), but does not explicitly state when not to use it or name alternatives among the sibling tools (e.g., design_search_images for image-only searches). The implied usage is strong but lacks explicit exclusions.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: design_extract_tokens extracts design tokens from live websites, design_search_images searches for images across design platforms, design_search_references searches for articles and documentation, and design_search_styles searches for aesthetic directions. There is no overlap in functionality, and the descriptions make their unique roles explicit.

Naming Consistency5/5

All tool names follow a consistent pattern: they start with 'design_' followed by a verb-noun combination (e.g., extract_tokens, search_images, search_references, search_styles). This uniformity makes the tool set predictable and easy to understand, with no deviations in naming conventions.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose of providing design inspiration resources. Each tool serves a distinct function in the design workflow (extraction, image search, reference search, and style search), and there are no redundant or missing tools that would suggest an inappropriate count.

Completeness5/5

The tool set covers the full lifecycle of design inspiration: searching for images, references, and styles, and extracting tokens from live sites. There are no obvious gaps, as the tools enable agents to find inspiration, analyze it, and apply it, providing comprehensive coverage for the domain.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Serper Search MCP Server

    NightTrek
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables integration of Google search functionality into MCP-enabled applications using the Serper API, providing rich search results, configurable parameters, and efficient response handling.
    48

  • Mobbin MCP Server

    pdcolandrea
    A
    license
    Not graded
    quality
    F
    maintenance
    Enables users to search and browse Mobbin's extensive library of mobile app designs, screenshots, and user flows directly from Claude. It allows for detailed exploration of UI patterns, elements, and personal collections using reverse-engineered API access.
    140
    45
    ISC

  • UI Design MCP Server

    lnksoul1
    A
    license
    A
    quality
    B
    maintenance
    Provides comprehensive UI design assistance tools for LLMs, generating color palettes, typography, spacing systems, shadows, design tokens, and more via the MCP protocol.
    28
    MIT

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/YonasValentin/design-inspiration-mcp-server'

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