Skip to main content
Glama
deenesjakoruzh
SankofaForge

design-inspiration

by SankofaForge
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

design-inspiration

MCP server that searches Awwwards.com for UI design inspiration. It works with Claude Code and other MCP clients.

Uses the Serper API with a site:awwwards.com filter. It can also extract design tokens from Awwwards.com pages with a headless browser.

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

Why

I wanted Claude to pull design references while building UI without leaving the terminal. The search tools return Awwwards.com pages that can be reviewed directly.

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

The token extraction tool reads an Awwwards.com page and reports its colors, fonts, spacing, borders, and shadows.

Related MCP server: mcp-mirage-brand-extract

Tools

design_search_references — Search current and past Awwwards Site of the Day winners. Honorable Mentions, nominees, and pages without an explicit, dated SOTD marker are filtered out.

design_search_styles — Search SOTD winners for a specific aesthetic direction. It combines image and web results for color, typography, layout, or animation queries, and keeps images only when their page also passed the SOTD filter.

design_prepare_references — Fetch each selected Awwwards page and verify its title or award heading identifies a dated Site of the Day win before normalizing the handoff. Each reference also requires a distinct, valid non-Awwwards liveUrl and a captureName accepted by the live capture server (1–81 letters, numbers, dots, dashes, or underscores). Honorable Mentions, nominees, missing award metadata, non-2xx responses, and timeouts fail the handoff.

design_extract_tokens — Extract design tokens from an Awwwards.com page. Supports dark_mode and mobile flags. Requires dembrandt installed globally (npm install -g dembrandt).

The supported search tools query Awwwards.com. They accept 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

The search tools append the exact "Site of the Day" marker and (site:awwwards.com/sites) to each query. They call Serper's /images or /search endpoint, restrict links to Awwwards site pages, and reject results marked Honorable Mention, Nominee, or unknown. A result must include the award marker and a month/day/year signal before it can enter the shortlist.

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 and structured data. It has a 60-second timeout. dembrandt runs as a global CLI, so the project has no extra npm dependency for token extraction.

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"

The SOTD filter is a quality floor, not a substitute for review. Shortlist at least three returned pages, check that each live URL still works, and capture the selected site before using its motion as implementation evidence. If the search returns no qualifying pages, report that gap instead of falling back to Honorable Mentions or nominees.

You can download a returned image URL and have Claude view it directly:

curl -sL "https://example-cdn.invalid/reference.jpg" -o /tmp/reference.jpg

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

License

MIT

Declarative 3D asset workflow

References can declare that a site concept needs 3D assets. design_prepare_references verifies the SOTD award, validates the asset requirement, and returns an assetPlan; it does not capture the site, create files, call Blender, or invoke another MCP.

The prepared reference preserves the indexed Awwwards url as source provenance and carries the selected live site through liveUrl. Asset-plan entries retain both as sourceReference and liveSiteUrl, so the capture handoff and asset provenance cannot be confused.

When an asset plan contains route: "blender", the host application or agent must resolve that task against its current capability manifest and route it to the available Blender MCP. This is host-level routing, not an invocation performed by this server. Preserve the asset ID and acceptance requirements in the Blender task. If Blender is unavailable, the host must return a blocked asset result instead of silently substituting CSS or a placeholder.

Use examples/blender-asset-task.json as the handoff shape. Include subject, visual intent, camera, composition, materials, lighting, animation, web-ready output formats, performance limits, and acceptance expectations. Web outputs normally include compressed .glb or .gltf plus a .png or .webp fallback. Acceptance verifies clean-viewer loading, framing, materials, animations, and performance budgets.

Expected handoff: design_prepare_references -> assetPlan.route = "blender" -> host application -> Blender MCP -> native site implementation and browser QA.

Do not replace a declared 3D requirement with CSS or a placeholder without user approval. If Blender is unavailable, report the blocked asset task and retain the declarative handoff.

Declarative 2D animation workflow

References can also declare animated SVG or Lottie deliverables. The server validates the animation requirements and returns an assetPlan route. It remains declarative and read-only with respect to asset authoring: it does not create asset files or call SVGator, Lottie Creator, Glaxnimate, or the brief-to-Lottie compiler.

Use kind: "animated-svg" for a web-native animated SVG, or kind: "lottie" when Lottie is the primary delivery format. Set preferredTool to "svgator" or "lottie-creator" when the default route should be overridden. Without an explicit tool, animated SVG routes to SVGator and Lottie routes to Lottie Creator.

The host application resolves each route against its connected capability manifest and preserves the asset ID and acceptance requirements:

  • svgator means the actual external SVGator MCP, not Glaxnimate. Its official endpoint is https://mcp.svgator.com/mcp. The host must have at least create_project, edit_part, and export_project available for this authoring handoff. The host owns those calls and keeps authentication outside the handoff and repository.

  • lottie-creator remains the simple brief-to-lottie compiler route for requests that fit its supported shape-layer SceneSpec/MotionSpec. Complex Lottie work must explicitly set kind: "lottie" and preferredTool: "svgator" in the input asset requirement. The server does not infer complexity or automatically upgrade the default route.

  • Glaxnimate is a separate, explicitly selected host-only route for a complete authored SVG with valid semantic IDs. It is not a preferredTool value in this server's schema and must never be an implicit fallback for svgator or lottie-creator.

If the requested capability is missing or incompatible, the host returns a blocked asset result with the original ID, route, and reason. It must not silently substitute Glaxnimate, handwritten SVG, CSS, or a placeholder.

Animation requirements include duration, loop behavior, trigger, reduced-motion behavior, and file-size or path-count budgets. For the SVGator example, acceptance requires Lottie JSON, a self-contained animated SVG, and a separate static reduced-motion output. The host must validate each exported file before accepting it: parse the JSON and SVG, check playback in the target Lottie player and browser, verify timing and trigger behavior, check that reduced motion shows the static output, and measure the file-size and path-count budgets. A successful export call alone does not establish acceptance.

See examples/svgator-asset-task.json for a complex vector/Lottie task in the host handoff shape. This example is not a direct design_prepare_references input: map assetId to the input asset requirement's id, pass preferredTool: "svgator", and use delivery: "web". Keep route, authoring, acceptance, and output paths in the host handoff, outside the server's strict input schema. The expected flow is design_prepare_references -> assetPlan.route = "svgator" -> host application -> SVGator MCP -> export validation -> native site implementation and browser motion QA.

Available Tools

5 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"
mobileNoExtract from mobile viewport (375px)
dark_modeNoExtract colors from dark mode variant

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

design_prepare_referencesPrepare design referencesA
Read-onlyIdempotent

Validate and normalize selected references. Does not browse, capture, or invoke other MCPs.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context by explicitly ruling out browsing, capturing, and invoking other MCPs, which goes beyond the structured 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?

Two short sentences deliver the core action and key exclusions with no wasted words. The most important operational information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, annotation-covered tool, the description fully covers what the tool does and what it avoids. The phrase 'selected references' assumes prior context, but the lack of parameters and strong annotations make this sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no parameter semantics for the description to clarify. The baseline for zero-parameter tools is 4, and the description does not need to compensate for any schema gaps.

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 specific verbs ('validate and normalize') and identifies the resource ('selected references'). It also explicitly distinguishes itself from sibling search tools by stating it does not browse, capture, or invoke other MCPs.

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 clearly positions the tool as a preparation step for already-selected references and tells the agent what it will not do. It implies the right conditions for use, though it does not explicitly name sibling alternatives as replacements.

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
numNoNumber of image results to return (1-40, default: 10)
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

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

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
numNoNumber of results to return (1-20, default: 10)
queryYesUI design search query. Examples: "best dashboard designs 2025", "mobile navigation patterns"
sitesNoFilter to specific design sites. Empty array searches all sites.

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

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
numNoNumber of results (1-20, default: 10)
typeNoType of style inspiration to search forgeneral
styleYesDesign style to search for. Examples: "minimalist dark theme", "brutalist web design", "glassmorphism"

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/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: 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.

Usage Guidelines3/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv1.0.0
    • First observeddesign_extract_tokens
    • First observeddesign_prepare_references
    • First observeddesign_search_images
    • First observeddesign_search_references
    • First observeddesign_search_styles
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored across 5 tools

Disambiguation4/5

The tools are largely distinct: search_images handles image lookup, search_references handles textual content, extract_tokens handles live site analysis, and prepare_references handles validation. However, design_search_styles blends image and web search for style-specific queries, which overlaps with the first two but is differentiated by its focus on aesthetic direction like color palettes and typography.

Naming Consistency5/5

All tools follow a consistent design_<verb>_<noun> pattern with snake_case and clear verbs (search, extract, prepare). No variation in casing or verb style, making the naming predictable and easy to navigate.

Tool Count5/5

With 5 tools, the server is well-scoped for a design inspiration use case. Each tool serves a distinct purpose—searching visuals, text, styles, extracting tokens, and preparing references—without unnecessary bloat or minimal coverage.

Completeness4/5

The surface covers the core workflow: search for inspiration (images, references, styles), extract tokens from a chosen site, and prepare references for use. Minor gaps exist, such as no explicit tool to fetch or save a specific reference beyond token extraction, but the primary use cases are well covered.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers