# Design inspiration MCP for GitHub Copilot [Open the live Fudge conversation](https://design.withfudge.com/share/design-inspiration-mcp-for-github-copilot) Last updated: 2026-08-25 GitHub Copilot becomes more useful for frontend work when it can work from inspected website references instead of a loose visual description. Connect an MCP server that gives Copilot access to saved design references, then use it to compare page structure, typography, colors, spacing, and components before generating code. ## The best workflow for Copilot Keep the process focused on decisions Copilot can implement: 1. **Choose references for a specific job.** Pick pages with a similar audience and goal, not just pages that look attractive. 2. **Ask for an evidence-based inventory.** Have Copilot list the visible sections, layout relationships, type hierarchy, colors, controls, cards, images, and surface treatments. 3. **Compare before combining.** Ask which reference is strongest for hierarchy, which is strongest for technical explanation, and which is strongest for navigation or conversion. 4. **Write a design brief.** Record the selected structure, tokens, components, and open questions in plain language. 5. **Build in small slices.** Ask Copilot to implement the shell, then the hero, then the main content pattern. Check each slice against the brief before moving on. The examples below include Notion Developer Platform, Claude Code, and Exa MCP Server. Use them to compare how developer-oriented pages can balance explanation, product confidence, and technical detail. They are useful visual references, but they are not a substitute for deciding what your own visitors need. ## 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) ## Ask Copilot for the right details A request such as "make this look like the reference" leaves too much room for guesswork. Instead, ask for a table with one row per reference and columns for: - Navigation and first-screen structure - Hero heading length, supporting copy, and primary action - Container width, columns, alignment, and spacing rhythm - Font families, available weights, sizes, and line heights - Background, text, border, accent, and muted colors - Button dimensions, radius, padding, and states - Card, code block, image, and testimonial treatment - Motion, clipping, overlays, and interactions that are visibly present Then ask Copilot to label each item as **observed**, **inferred**, or **to verify**. That distinction is valuable when the reference is a captured page and the implementation must work across browsers and screen sizes. ## Compare references without losing direction Use this quick scoring method before choosing a pattern. Give each reference a score from one to five for clarity, relevance, reuse, restraint, and ease of adaptation. A reference with a beautiful animation but weak page structure should not automatically become the main model. | Decision | Choose the reference that... | | --- | --- | | Hierarchy | makes the main product and next action easiest to understand | | Technical content | explains tools or workflows without overwhelming the first screen | | Components | offers patterns you can reuse across several sections | | Visual system | has a small, coherent set of type, color, and surface choices | | Adaptation | can be changed without relying on its brand assets | Use one reference as the structural base. Borrow a secondary pattern only when it solves a clear problem, such as presenting code, showing integrations, or organizing feature details. ## Turn the comparison into a Copilot handoff Before asking for a complete page, produce a short handoff with the selected layout, token values, component names, content limits, and responsive rules. Include explicit boundaries: do not copy logos, illustrations, screenshots, or text; do not invent a mobile behavior that was not observed; and do not treat an extracted reference as the official design system for the source site. The connected reference workflow can also help inspect fonts, color roles, contrast, images, motion, and page state, then export observed details to Tailwind v4, CSS, JSON, or DESIGN.md. Use those outputs as starting material, and review them against your product requirements before merging code. ## Use this in your AI agent > Use MCP to inspect my saved website design references while I work with GitHub Copilot. For each reference, return an evidence-based inventory of page sections, layout, typography, colors, spacing, borders, radii, shadows, images, motion, and visible interactions. Compare the references in a table, label observations separately from inferences, and recommend one primary structure for my page. Then create a frontend handoff with Tailwind v4 tokens, reusable component names, responsive questions to verify, and implementation boundaries. Do not copy brand assets, text, or unsupported assumptions. Reference examples: Notion Developer Platform, Claude Code, and Exa MCP Server. Page goal: [describe the page]. Audience: [describe the audience]. [Install Fudge for your AI agent](/mcp) --- Give Copilot constraints that force it to solve your page's problem rather than reproduce another brand. State the audience, page goal, primary action, content limits, technical stack, and the parts of the reference you want to study. For example, you might borrow the order of sections and the treatment of technical content, while requiring new copy, new imagery, and a different color system. Ask Copilot to work in three passes: 1. **Explain:** list the observed layout and visual rules without writing code. 2. **Adapt:** propose a version for your product, with a short reason for every borrowed pattern. 3. **Implement:** build only the approved structure using your existing components and tokens. Also tell it what not to do: do not copy logos, illustrations, screenshots, wording, or distinctive brand treatment; do not invent responsive behavior; and do not add sections just because they appeared in the reference. Review the first implementation at desktop and mobile widths. If the result feels too similar, change the content hierarchy and visual tokens before changing small decorative details. --- Give Copilot a one-page handoff that is specific enough to implement but short enough to review. Start with the page goal and the single action visitors should take. Next, define the structure in order, such as navigation, hero, proof, feature explanation, integration details, call to action, and footer. Add a token table for the chosen font families, weights, heading sizes, body size, line height, background colors, text colors, borders, accents, spacing steps, radii, and shadows. Follow it with a component list and each component's job. Include content limits, for example the maximum heading length, the number of cards, and whether a code sample is required. Finish with responsive rules and verification questions. Note what must stack, what can scroll, what remains visible, and what still needs a browser check. Ask Copilot to return a checklist after implementation: structure matched, tokens reused, keyboard states included, contrast reviewed, and reference assets replaced. This handoff turns visual inspiration into a clear build plan rather than an instruction to imitate a page. ## Related questions - [Design inspiration MCP for Windsurf](/share/design-inspiration-mcp-for-windsurf) - [MCP Server for Website Design References](/share/mcp-server-for-website-design-references) - [Use Real Website Examples Inside Claude Code](/share/real-website-examples-inside-claude-code) - [Use website design references inside Cline](/share/real-website-examples-inside-cline)