# Website design research MCP for Gemini CLI [Open the live Fudge conversation](https://design.withfudge.com/share/website-design-research-mcp-for-gemini-cli) Last updated: 2026-08-25 Website design research MCP for Gemini CLI is useful when you want Gemini CLI to build from concrete website references rather than a loose request for a modern look. The reliable method is to collect a small reference set, compare matching page elements, and pass Gemini CLI a decision-focused brief before it writes code. ## A practical workflow for Gemini CLI 1. **Choose two to four references.** Use pages that solve a similar visitor problem, such as a developer page, documentation site, signup flow, or product dashboard. A useful reference answers a design question. It is not simply a page you happen to like. 2. **Review equivalent sections together.** Compare the opening section with the opening section, cards with cards, and forms with forms. Check navigation, content width, heading scale, buttons, spacing, color roles, borders, and responsive behavior. This helps you spot patterns that repeat across different pages. 3. **Turn observations into decisions.** Write choices such as “use a medium-width content column,” “keep the background warm and quiet,” or “use one high-contrast action per section.” Gemini CLI can then implement a direction instead of guessing what “similar” means. 4. **Build in stages.** Ask for the page structure first, then typography and spacing, then reusable components, then responsive refinements. Inspect each stage before asking for the next one. Open the examples below as a starting shortlist. They include Notion Developer Platform, Claude Code, and Exa MCP Server. Compare the parts relevant to your task, and do not assume that a recognizable product page is automatically the right model for your content or audience. ## 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 capture in your research notes A compact comparison table keeps the prompt useful: | Area | Reference A | Reference B | Decision for this page | | --- | --- | --- | --- | | Content width | narrow, medium, or wide | narrow, medium, or wide | selected max width | | Opening layout | text-led, visual-led, or split | text-led, visual-led, or split | chosen structure | | Typography | family, size, weight, line height | family, size, weight, line height | role assignments | | Colors | background, text, accent | background, text, accent | approved roles | | Components | cards, code, tabs, forms | cards, code, tabs, forms | pieces to reuse | | Small screens | stack, scroll, hide, or resize | stack, scroll, hide, or resize | responsive rules | Prefer observations over taste words. “The page feels clean” does not tell Gemini CLI what to change. “The body copy sits in a short measure, headings use a strong weight, and sections have large vertical gaps” gives it a usable direction. When a value is uncertain, call it an estimate and keep it easy to tune. ## How to brief Gemini CLI Start with the existing project context: framework, route, component library, styling system, and current page behavior. Then separate the reference notes from your requirements. The references can guide composition and visual hierarchy, but they should not override your content, accessibility, performance, or product constraints. Ask Gemini CLI to inspect the current implementation before editing. Request a file-level plan, identify reusable components, and limit the first pass to the page shell. After reviewing it, describe mismatches precisely. “The hero is too tall,” “the text column needs a tighter measure,” and “the card borders are too prominent” are actionable corrections. “Make it feel more like the reference” is not. ## A checklist before you ship Check the primary action, reading order, text contrast, focus visibility, spacing consistency, mobile stacking, and reuse of shared components. Compare the first screen and one dense section against the references. Confirm that decorative elements support the content instead of competing with it. Remove anything that was added only because it appeared in a reference. Fudge fits this workflow as a research step inside Gemini CLI: use it to inspect captured pages, compare type and color details, and give the agent a grounded brief for the implementation you actually need. ## Use this in your AI agent > Use Fudge to compare the saved website references for this page. Return a concise research brief covering the opening layout, content width, typography roles, color roles, spacing, buttons, cards, and responsive behavior. Clearly label observed details, estimates, and recommendations. Then inspect this Gemini CLI project and propose the smallest implementation plan that reuses its existing components and preserves current behavior. Build only the page shell first, explain the decisions, and wait for the next refinement step. [Install Fudge for your AI agent](/mcp) --- Treat the shared styles as constraints and the references as evidence for decisions. Start by listing the existing tokens and components Gemini CLI should reuse, then describe the visual result you want in terms of roles: content width, heading scale, spacing, surface treatment, action hierarchy, and responsive behavior. Ask Gemini CLI to map each decision to an existing style or component. If one does not fit, request the smallest extension rather than a parallel system. Have it build one representative section, such as the opening section plus one card group, so you can check the direction before the pattern spreads across the page. Keep the prompt explicit about what must not change: shared navigation, routes, content semantics, keyboard behavior, and unrelated screens. Ask for a summary of reused styles, new styles, and unresolved questions. This makes the visual comparison useful without turning a reference page into an accidental rewrite of the project. --- Write the prompt as a short design brief followed by an implementation plan. State the visitor goal first, then name the references and list concrete observations: opening structure, content measure, heading hierarchy, button order, card density, color roles, spacing rhythm, and narrow-screen behavior. Next, state your decisions and constraints. Say which patterns are inspiration, which are requirements, and which values are estimates. Tell Gemini CLI which route and files it may change, which existing components it must reuse, and what accessibility or content rules must remain intact. Finish with staged work: inspect the current page, propose the smallest plan, implement the shell, report what changed, and stop before polishing. When reviewing the result, give one specific correction at a time. A note like “reduce the gap between the heading and supporting copy” will lead to a cleaner iteration than a broad request to make the page more faithful. ## Related questions - [Website Design Research MCP for GitHub Copilot](/share/website-design-research-mcp-for-github-copilot) - [Website design system MCP for Claude Code](/share/website-design-system-mcp-for-claude-code) - [Use Website Design References in Claude Desktop](/share/website-design-system-mcp-for-claude-desktop) - [Website design research MCP for Claude Desktop](/share/website-design-research-mcp-for-claude-desktop)