Searches Awwwards for UI design inspiration, providing tools to find visual references, design patterns, and case studies.
Searches Behance for UI design inspiration, providing tools to find visual references, design patterns, and case studies.
Searches Dribbble for UI design inspiration, providing tools to find visual references, design patterns, and case studies.
Uses Google Search via the Serper API to perform scoped searches across design platforms for images, design references, and articles.
Searches Pinterest for UI design inspiration, providing tools to find visual references, design patterns, and case studies.
Click on "Deploy 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 Inspiration MCP Server find dark mode fintech dashboard examples on Dribbble"
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.
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.
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-forge
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.
You need a Serper API key for the search tools. Free tier gives you 2,500 searches with no credit card.
Sign up at serper.dev
Copy your API key
For token extraction, install dembrandt globally:
npm install -g dembrandtclaude mcp add design-inspiration -e SERPER_API_KEY=your-key-here -- node /path/to/design-inspiration-mcp-server/dist/index.js{
"design-inspiration": {
"type": "stdio",
"command": "node",
"args": ["/path/to/design-inspiration-mcp-server/dist/index.js"],
"env": {
"SERPER_API_KEY": "your-key-here"
}
}
}git clone https://github.com/YonasValentin/design-inspiration-mcp-server.git
cd design-inspiration-mcp-server
npm install
npm run buildEach 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.
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.jpgThen ask Claude to read the image file — it can see and describe the design.
MIT
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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Website URL to extract design tokens from. Examples: "https://stripe.com", "https://linear.app" | |
| dark_mode | No | Extract colors from dark mode variant | |
| mobile | No | Extract from mobile viewport (375px) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the description is relieved of safety disclosure. It adds valuable behavior: 'using headless browser' implies the tool fetches the live page and could be subject to site access or latency, and 'get back the exact values' hints at the output precision. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with zero fluff. It front-loads the primary purpose in the first sentence, then reinforces scope and integrates with siblings. Every sentence earns its place, making it concise and well-structured.
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?
The tool is simple (3 params, 1 required, booleans with defaults) and has no output schema, so the description need not detail return structure excessively. It covers the purpose, usage context, and practical behavior adequately. Minor gaps like error handling or return format are not critical given the simplicity and existing annotations.
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?
The input schema has 100% description coverage, so all three parameters (url, mobile, dark_mode) are already fully documented. The description adds no additional meaning about parameter usage or semantics, so it sits at the baseline of 3 as per the rubric.
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 uses a specific verb 'Extract' and a clear resource 'design tokens', enumerating the token categories (colors, typography, spacing, borders, shadows) and specifying it works on a live website via headless browser. This clearly distinguishes it from sibling search tools, which are about finding references, while this actually extracts values.
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 provides usage context by stating 'Give it any URL and get back the exact values used' and explicitly pairs it with search tools: 'find inspiration, then extract tokens from sites you like.' This implies a clear workflow, but it refers to 'search tools' generically without naming the specific sibling tools (e.g., design_search_styles), so it lacks the explicit alternative routing seen in the highest-scoring examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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").
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | UI design search query. Examples: "dashboard dark mode", "mobile onboarding flow", "saas pricing page" | |
| sites | No | Filter to specific design sites. Empty array searches all sites. Options: dribbble, behance, awwwards, mobbin, pinterest | |
| num | No | Number of image results to return (1-40, default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive, which already establish safety. The description adds that it performs image search across specific sites and returns certain metadata, but doesn't disclose behaviors like pagination, rate limits, or result ordering, which might be relevant for a search tool. It doesn't contradict annotations, but adds minimal new behavioral context beyond the search scope.
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 concise, at two sentences, with the core function stated upfront and the searching tip as a secondary sentence. Every sentence adds value without redundancy.
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?
The tool is simple with three parameters, a clear output description in the description text, and extensive annotation coverage (read-only, idempotent). The description adequately covers: what it searches, what it returns, and query guidance. However, it lacks details on result pagination or how to interpret the returned metadata, but given the simplicity and annotations, it's sufficiently complete.
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?
The input schema already provides descriptive parameter documentation, with near 100% coverage (the 'sites' parameter includes enum values and explanation). The description reinforces the need for specific query terms but doesn't add much beyond the schema. For 'num' and 'sites', the schema covers their usage, so the description adds limited value here.
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 searches images across specified sites and returns URLs, dimensions, and source links. It uses a specific verb and resource, distinguishing it from sibling tools which focus on references or styles. However, it doesn't explicitly differentiate from design_search_styles, which might overlap, but the image-search focus is clear.
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?
It provides explicit advice on query phrasing: use specific UI terms over vague ones, which guides when to use this tool effectively. However, it doesn't contrast against sibling tools like design_search_styles or design_search_references, leaving it to the agent to infer which search is appropriate based on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | UI design search query. Examples: "best dashboard designs 2025", "mobile navigation patterns" | |
| sites | No | Filter to specific design sites. Empty array searches all sites. | |
| num | No | Number of results to return (1-20, default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description conveys that this is a read-only operation that is safe and idempotent. It adds the useful behavioral note that it searches the web, not a local database, and that it returns web results rather than being limited to visual output. It doesn't cover what happens with image search, but for a read query this is reasonable and exceeds the annotations alone.
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 only two sentences, but those two sentences contain actionable guidance. The first sentence states what it does, and the second highlights when to use it over an alternative. This is efficient and well-structured.
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 read-only search tool with no output schema, the description covers the return value types and the when-to-use scenario. It doesn't mention pagination or result limits, but those are available in the schema. The sibling tools are not referenced to direct the agent toward or away from them, which would be a minor improvement.
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?
The schema covers 100% of parameter descriptions, including examples for query and valid sites. The description field in the schema provides good context, so the main description isn't burdened with parameter details. However, the description does reference the general purpose and output type, which gives the agent a high-level expectation of what the parameters accomplish. Given full schema coverage, this is a solid 3.
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 states a specific verb ('web search scoped to design platforms') and the return types (article titles, snippets, links). It doesn't explicitly distinguish from the two sibling search tools, but the scoping gives useful context. The examples in the schema parameters provide additional clarity.
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 gives a when-to-use comparison against image search, which is a clear alternative. It fails to mention when image search might be better, but it does name one specific use case where this tool excels (case studies, write-ups, documentation), giving the agent a practical rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for a specific aesthetic direction — color palettes, typography, layouts, or animation references. Runs image and web search in parallel and returns combined results.
| Name | Required | Description | Default |
|---|---|---|---|
| style | Yes | Design style to search for. Examples: "minimalist dark theme", "brutalist web design", "glassmorphism" | |
| type | No | Type of style inspiration to search for | general |
| num | No | Number of results (1-20, default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent, open-world), the description discloses that it runs image and web searches in parallel and merges results — genuinely useful operational knowledge an agent wouldn't get from the schema alone. This tells the agent to expect combined, multi-source output from a single call. The annotations already cover the safety profile, so the description earns credit for adding the execution model on top.
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 tight sentences: the first front-loads the purpose with concrete examples, the second covers the single non-obvious behavioral trait (parallel execution). Not a single wasted word.
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 read-only search tool with three well-documented parameters, the description covers purpose, scope, and combined-result behavior. The main gaps are an unspecified return format (no output schema exists) and no disambiguation from the similarly named sibling tools — minor for a low-risk, read-only operation.
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%, so all parameters (style, type, num) are already documented. The description's style examples map naturally onto the type enum values ('color-palette', 'typography', 'layout', 'animation'), which provides a slight bridge between intent and schema. But it adds no format, syntax, or behavior details that the schema doesn't already state, landing at a solid baseline.
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's purpose: searching for a specific aesthetic direction with concrete examples like color palettes, typography, layouts, and animation references. The parallel image/web search detail adds specificity beyond a generic search. However, it doesn't explicitly distinguish itself from the closely related siblings design_search_images or design_search_references, which an agent would need to infer on its own.
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 opening 'Search for a specific aesthetic direction' conveys when to use the tool, and the style examples give useful intent context. But there's no explicit when-not-to-use guidance or any mention of alternatives, which is a real gap given sibling tools like design_search_images and design_search_references are topically adjacent. Usage is implied rather than stated.
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.
v1.0.0design_extract_tokensdesign_search_imagesdesign_search_referencesdesign_search_stylesScored across 4 tools
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.
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.
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.
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.
Search curated design styles, real product screens, and user flows for evidence-based design work.
Serper MCP — wraps the Serper Google Search API (serper.dev)
A design-style library for AI agents: search real styles, fetch a ready-to-apply design spec.
Find UI components and themes, retrieve code, and generate with hosted 21st AI when enabled.
