# Website reference MCP for Gemini CLI [Open the live Fudge conversation](https://design.withfudge.com/share/website-reference-mcp-for-gemini-cli) Last updated: 2026-08-25 A website reference MCP for Gemini CLI turns saved website examples into clear design guidance that Gemini can use while coding. The most reliable method is to ask for concrete observations first, choose a direction second, and request code only after the visual decisions are written down. ## The method that works Start with a small reference set. Pick one example for page structure, one for a useful component pattern, and one for a distinct visual quality such as typography or color. Then ask Gemini CLI to compare them against a specific screen in your project. A focused comparison is more useful than a broad request for inspiration. Use this sequence: 1. **Inspect the references.** Ask for the visible sections, layout relationships, typography, colors, controls, cards, imagery, and states. 2. **Summarize the differences.** Have Gemini explain what each reference does well and where each approach could create problems for your content. 3. **Choose a direction.** State which qualities you want to keep and which you want to avoid. 4. **Build a small system.** Ask for tokens, reusable components, responsive rules, and an implementation order. 5. **Review the rendered page.** Compare the result with the chosen direction and fix the largest mismatches first. Open the examples below as a starting point. The Notion Developer Platform, Claude Code, and Exa MCP Server examples are useful prompts for comparing different ways to present technical products. Do not treat any one card as a complete recipe. Look for the structure and visual choices that answer your own visitors' questions. ## 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 Gemini CLI should return Ask for a design brief with five parts: - **Page map:** the order and purpose of each visible section. - **Layout notes:** container width, columns, alignment, spacing, cards, and mobile behavior. - **Type notes:** font families, weights, sizes, line heights, label treatment, and heading contrast. - **Color roles:** page background, surface, text, muted text, accent, border, focus, success, and danger. - **Component map:** which buttons, cards, inputs, navigation elements, and content blocks should be shared. This format makes the result practical for a codebase. It also exposes uncertainty. If a detail is not visible in the reference, Gemini should label it as a recommendation rather than present it as a fact. ## Pick references by the job For a developer-facing page, use the examples according to the question you are trying to answer: - **Information grouping:** begin with the Notion Developer Platform example and study how a technical audience might move through the page. - **Coding-tool presentation:** use the Claude Code example to discuss how the product and workflow could be introduced. - **MCP explanation:** use the Exa MCP Server example to explore ways to make a technical service understandable without relying on a wall of setup text. When the examples point in different directions, choose based on visitor action. If visitors need to understand the product before trying it, favor clarity and progression. If they already understand the category, a denser layout may help them reach the relevant action faster. ## Keep the implementation grounded Ask Gemini CLI to translate observations into a compact set of design tokens rather than scattered one-off values. Include spacing, type sizes, colors, border widths, radii, shadows, and breakpoints. Then request components that use those tokens consistently. Before you keep the implementation, check the page at desktop and mobile widths, review keyboard focus, test long headings and short labels, and verify readable contrast. Also check that the reference influenced the design without replacing your own content or brand. If the page feels close but uneven, ask Gemini to identify the three largest differences and fix only those first. A reference-based workflow is most useful when it leaves you with decisions you can explain. The final result should have a clear page purpose, a repeatable visual system, and a short checklist for future sections. ## Use this in your AI agent > Use my saved website references as design evidence for this Gemini CLI task. Inspect and compare their page structure, typography, color roles, spacing, components, imagery, and visible states. Clearly separate observed details from recommendations. Create a design brief for my project with a page map, token list, reusable component map, responsive checklist, accessibility checks, and implementation order. Borrow useful patterns without copying brand-specific content or assuming behavior that is not visible. [Install Fudge for your AI agent](/mcp) to work with website references from Gemini CLI. --- Tell Gemini exactly what to compare and explicitly ask for adaptation. The important distinction is between an observed pattern, a reason it may help, and a recommendation for your project. > Compare these saved website references for my developer landing page. Inspect hierarchy, section order, content width, spacing, typography, color roles, card structure, buttons, and visible states. For every useful pattern, explain the visitor problem it solves. Then recommend an adapted version using my content, brand, and accessibility requirements. Do not copy wording, logos, imagery, or brand-specific styling, and label any detail that is not directly visible as a recommendation. You can follow that with a second prompt asking Gemini to create a token set and component plan from the selected recommendations. This keeps the agent from treating a screenshot as a specification and gives you a design direction you can review before code changes begin. --- Ask for implementation in stages. First request tokens for color roles, spacing, type scale, borders, radii, shadows, and responsive breakpoints. Next request a component map that identifies repeated patterns and their states. Then ask for the page shell and one representative section before generating the rest. Use a checklist such as: - Does the page purpose appear immediately? - Are heading sizes and line lengths readable on narrow screens? - Do repeated cards share spacing and alignment? - Are buttons, inputs, and focus states consistent? - Do colors retain enough contrast across backgrounds and states? - Does the chosen reference direction still fit the actual content? A focused review prompt can be: > Review the current implementation against the selected design brief. Report the three largest issues in hierarchy, spacing, typography, color, responsiveness, or component consistency. For each issue, show the smallest change that fixes it, then apply only those changes and summarize what remains intentionally different from the references. That process gives Gemini room to adapt the references while keeping the resulting code coherent. ## Related questions - [Website references for GitHub Copilot](/share/website-reference-mcp-for-github-copilot) - [Use Website References in Cursor with an MCP Server](/share/website-reference-mcp-for-cursor) - [Website reference MCP for Windsurf](/share/website-reference-mcp-for-windsurf) - [Best design MCP for AI coding agents](/share/best-design-mcp-for-ai-coding-agents)