# Website Design System MCP for Windsurf [Open the live Fudge conversation](https://design.withfudge.com/share/website-design-system-mcp-for-windsurf) Last updated: 2026-08-25 A website design system MCP for Windsurf is most useful when it gives your coding agent concrete website references to inspect while you build. Instead of asking for a page that merely feels similar to a screenshot, give Windsurf a focused job: compare selected references, record visible design decisions, and apply only the choices that support your page. ## Start with the page goal Before comparing references, name the page you are improving and the action it should support. A developer landing page, documentation page, pricing page, and setup page need different structures. Tell Windsurf what content must remain, which components it may change, and which existing interaction must continue working. A useful first request is: > Inspect my saved website references for the page I am improving. Compare the hero structure, navigation, heading hierarchy, content width, buttons, cards, code examples, borders, colors, and narrow-screen behavior. Separate visible observations from recommendations. Choose only the patterns that support my page goal, and explain why. This keeps the comparison tied to a real implementation instead of producing a list of attractive but unrelated ideas. Open the examples below and compare their first screen, content density, calls to action, and treatment of technical content. The Notion Developer Platform, Claude Code, and Exa MCP Server references offer different starting points for studying developer-focused pages. Use them as visual references, not as proof that one structure is correct for your product. ## Captured pages [![Notion Developer Platform](https://pin.fontofweb.com/9283?format=jpg)](https://design.withfudge.com/share/pin-9283) [Notion Developer Platform](https://design.withfudge.com/share/pin-9283) [![Claude Code](https://pin.fontofweb.com/1446?format=jpg)](https://design.withfudge.com/share/pin-1446) [Claude Code](https://design.withfudge.com/share/pin-1446) [![Exa MCP Server](https://pin.fontofweb.com/6429?format=jpg)](https://design.withfudge.com/share/pin-6429) [Exa MCP Server](https://design.withfudge.com/share/pin-6429) ## Compare details that affect code Ask Windsurf to return a short table before it edits anything. Include these columns: reference, observed detail, proposed adaptation, reason, and manual check. The comparison should cover: - **Structure:** section order, hero composition, columns, content width, and calls to action. - **Typography:** family, weight, size, line height, heading contrast, and text measure. - **Color roles:** page background, surfaces, text, muted text, links, actions, borders, and highlights. - **Spacing:** navigation gaps, section padding, card gaps, button padding, and paragraph rhythm. - **Components:** buttons, inputs, code examples, cards, tabs, notices, and navigation states. - **Responsive behavior:** what stacks, wraps, resizes, moves, or disappears on a narrow screen. Request measurements only when the reference provides enough information to support them. Otherwise, ask Windsurf to describe the relationship, such as a compact gap or a wide content column, and label the value as an adaptation. ## Turn observations into a small system Once you choose a direction, define a limited set of reusable values: page and surface backgrounds, primary and muted text, action color, border color, spacing steps, radius steps, shadow levels, type sizes, line heights, and content widths. Map those values to the target components instead of adding a new value for every element. Give Windsurf explicit implementation boundaries: > Apply the approved design rules to [page or components]. Preserve the existing wording, routes, form behavior, and primary action. Reuse existing styles where possible. Change only the hero, navigation, buttons, cards, and code example styles supported by the comparison. Verify narrow-screen wrapping, keyboard focus, readable contrast, consistent spacing, and text overflow. Report changed files, adapted decisions, and remaining manual checks. ## Keep references honest A captured page can show appearance without proving its hidden interactions, licensing, source files, or complete responsive behavior. Ask Windsurf to mark those items as unverified. Do not assume that a displayed font is available for your project or that a reference button behaves like your own button. Avoid combining several unrelated structures. Choose one primary model, then borrow a few supporting details such as a type scale, border treatment, or code-block style. Review the result with your own content at desktop and narrow widths. If the page becomes harder to scan, the reference has not improved the design. ## Use this in your AI agent > Use my saved website references as design evidence for this Windsurf task. Compare page structure, typography, color roles, spacing, component shapes, and responsive behavior. Separate observed details from recommendations and flag anything unverified. Propose a compact design system for the target page, apply only approved changes, preserve existing routes and interactions, and finish with changed files, accessibility checks, and differences from the references. [Install Fudge for your AI agent](/mcp) to use website design references during this workflow. --- Ask for a structured comparison before asking for code. Name the target page and limit the comparison to decisions that affect it. > Compare my saved references for navigation structure, hero composition, content width, heading scale, button hierarchy, card treatment, color roles, and narrow-screen behavior. Return one row per reference, then recommend one structure and up to three supporting patterns for my page. Do not copy wording, branding, illustrations, or unverified interaction behavior. Explain why each selected pattern fits my content. After the comparison, approve only the patterns that improve the page's actual job. Keep the existing routes, form behavior, and primary action unless you have a separate reason to change them. --- Include the target page, allowed files or components, reference details to use, details that must remain original, and checks for a successful result. > Inspect my saved references, then update [target page]. Use the observed type hierarchy, spacing rhythm, surface and border treatment, button hierarchy, and responsive structure as input. Keep the product wording and brand identity original. Do not invent font licensing, interaction behavior, or accessibility results. Change only [files or components]. Verify mobile stacking, keyboard focus, readable contrast, consistent values, and the existing primary action. Summarize observations, adapted decisions, changed files, and remaining manual checks. Ask for design values and component rules in a separate section if you want a handoff that can be reviewed before implementation. ## Related questions - [Website Reference MCP for Claude Code](/share/website-reference-mcp-for-claude-code) - [Website design system MCP for GitHub Copilot](/share/website-design-system-mcp-for-github-copilot) - [Website references for Claude Desktop](/share/website-reference-mcp-for-claude-desktop) - [Website Design System MCP for Gemini CLI](/share/website-design-system-mcp-for-gemini-cli)