# Website design research MCP for Windsurf [Open the live Fudge conversation](https://design.withfudge.com/share/website-design-research-mcp-for-windsurf) Last updated: 2026-08-25 If you want website design research inside Windsurf, connect an MCP server that lets your coding agent search saved references and inspect captured pages while you work. The useful workflow is to collect a small reference set, compare the parts that matter, then ask Windsurf to turn those observations into implementation-ready guidance. ## A practical workflow for Windsurf Start with three to five references that match the job you are doing. For a landing page, collect pages with a similar audience, content density, and conversion goal. For a dashboard, collect products with comparable navigation, tables, filters, and empty states. Avoid collecting a large moodboard before you know what you need to compare. Then ask your agent to review the references using a fixed checklist: 1. What appears in the opening viewport? 2. How are the header, navigation, and primary action arranged? 3. Which sections repeat across the examples? 4. What type scale, font weights, spacing, colors, borders, and radii are visible? 5. Which patterns fit the current product, and which should not be copied? This keeps the result focused on decisions rather than a pile of screenshots. The examples below include Notion Developer Platform, Claude Code, and Exa MCP Server. Open them and compare the first screen before borrowing a pattern. Their inclusion gives you concrete references to discuss, but you should still verify each observation against the captured page before using it in a build. ## 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) ## What to ask the agent to inspect A strong request separates observation from recommendation. Ask Windsurf to first list what is visible, including the page sections, component relationships, viewport behavior, typography, colors, and spacing. Next, ask it to identify repeated patterns across the references. Only then ask for a proposed direction for your own page. For example, you might request: > Compare these references for a developer-facing landing page. List observed header structure, hero layout, content width, type hierarchy, button treatment, section spacing, card styling, and mobile considerations. Mark each point as observed or recommended. Then propose a small set of reusable components for my existing codebase. That wording helps prevent an agent from presenting an invented design decision as if it came from a reference. ## Turn research into code decisions Use the research to create a short design brief before asking for implementation. Include the page goal, the intended audience, the sections to build, the type hierarchy, the color roles, spacing rules, component states, and the patterns you explicitly reject. Keep it specific enough that another developer could review it without opening every reference. A useful brief might say: - Use a compact header with one clear primary action. - Keep the hero readable at a narrow content width. - Use one display size, two body sizes, and a distinct label style. - Reserve the strongest color for actions and selected states. - Define card padding and border treatment once, then reuse them. - Check the mobile layout separately instead of shrinking the desktop composition. The exact values should come from the references you verify and your product constraints, not from assumptions. ## What to check before shipping Before implementation is considered finished, compare the built page with the brief rather than with a single screenshot. Check whether the opening viewport communicates the product clearly, whether headings and buttons have a consistent hierarchy, whether spacing remains intentional between sections, and whether the important action remains easy to find on smaller screens. Also separate observed design details from ownership of an official internal design system. A captured page can inform your choices, but it does not automatically provide the original source tokens, component rules, or permission to copy protected brand assets. Use the references as research, document your adaptations, and verify any assets or brand requirements independently. For ongoing work, save the references by project and keep the final brief beside the code. When the page changes, ask the agent to compare the current implementation against that brief and identify only the highest-impact differences. That produces a repeatable review instead of restarting research for every component. ## Use this in your AI agent > Review the saved website references for my Windsurf project. Compare their opening viewport, navigation, layout, typography, colors, spacing, cards, buttons, and responsive behavior. Separate observed details from recommendations, identify patterns that fit my product goal, and write a concise implementation brief with reusable components and a checklist for reviewing the finished page. [Install Fudge for your AI agent](/mcp) --- Ask Windsurf to compare the parts that affect structure and implementation, not just whether the references feel polished. Start with the opening viewport: header height, logo placement, navigation density, hero width, heading scale, supporting text, and primary action. Then compare section order, content width, card dimensions, border treatment, and how examples or technical details are introduced. For a developer audience, also check whether the page makes the next action obvious, how code or product screens are presented, and whether the layout remains readable when long labels wrap. Ask the agent to record each point as either observed, inferred, or recommended. That distinction is valuable when a screenshot does not reveal behavior. A focused prompt is: "Compare these references for a developer landing page. Create a table for header, hero, CTA, code or product proof, section rhythm, type hierarchy, colors, cards, and mobile behavior. Mark what is directly observed, then recommend only the patterns that fit my product and explain why." --- Turn the comparison into a one-page brief before asking Windsurf to edit code. Begin with the page goal and the visitor's next action. Follow with the section order, content width, typography roles, color roles, spacing scale, component states, and responsive rules. Add a short list of patterns to avoid so the agent does not copy every reference equally. Then ask Windsurf to map each decision to the existing project structure. It should identify which components can be reused, which need a narrow extension, and which are genuinely new. Request small implementation steps, such as header first, hero second, repeated cards third, and responsive review last. After each step, compare the result against the brief. End with acceptance checks: the first screen is clear without scrolling, the main action remains visible on small screens, repeated components share the same rules, and no reference-specific branding or unverified design tokens were copied as fact. ## Related questions - [Website design system MCP for Claude Code](/share/website-design-system-mcp-for-claude-code) - [Website Design Research MCP for GitHub Copilot](/share/website-design-research-mcp-for-github-copilot) - [Use Website Design References in Claude Desktop](/share/website-design-system-mcp-for-claude-desktop) - [Website design research MCP for Gemini CLI](/share/website-design-research-mcp-for-gemini-cli)