Website design feedback MCP for Gemini CLI

Contents

• [Start with a focused comparison](#start-with-a-focused-comparison)
• [Use a comparison table](#use-a-comparison-table)
• [A checklist for reviewing the advice](#a-checklist-for-reviewing-the-advice)
• [Turn the comparison into changes](#turn-the-comparison-into-changes)
• [Use this in your AI agent](#use-this-in-your-ai-agent)

For website design feedback in Gemini CLI, connect an MCP workflow that gives the agent captured page references it can compare directly. The useful process is to ask Gemini to inspect structure and visual choices first, then turn the strongest findings into a focused revision plan for your website.

Start with a focused comparison

Pick three to five references that solve a similar communication problem. A developer tool page, an AI coding product page, and an MCP server page may all be relevant, but each can use a different hierarchy. The Notion Developer Platform, Claude Code, and Exa MCP Server examples below are useful starting points for comparing developer-oriented presentation. Treat them as references to study, not templates to copy.

Ask Gemini CLI to compare the pages in this order:

1. Opening message: What the visitor learns first and how quickly the product's purpose becomes clear.
2. Page structure: Which sections appear before the first major action and how supporting information is grouped.
3. Visual hierarchy: Headline width, paragraph length, button emphasis, navigation density, and card placement.
4. Typography: Families, weights, sizes, line heights, casing, and the relationship between headings and body text.
5. Color and surfaces: Backgrounds, text roles, accents, borders, shadows, gradients, and contrast.

Request observations with evidence from the captured pages. If a detail is not visible, Gemini should mark it as unknown rather than filling the gap with a guess.

Use a comparison table

A table keeps feedback practical. Ask for columns named reference, observed choice, possible purpose, fit for my page, and recommended action. This prevents broad comments such as "make it more modern" from becoming an untestable redesign.

For example, instead of asking for a generic critique, ask: "Compare how each page introduces a developer tool, how much copy appears before the main action, and how visual examples support the explanation. Recommend one structure for my page and explain what I would give up by choosing it."

Then ask Gemini to separate reusable decisions from brand-specific details. A strong reusable decision might be a restrained card hierarchy or a clear relationship between a product explanation and a code example. A brand-specific decision might be a logo treatment, illustration style, or distinctive color combination that would not belong on your page.

A checklist for reviewing the advice

Use this checklist before accepting a recommendation:

• Does the first section explain the product in the visitor's vocabulary?
• Is there one obvious next action?
• Can the page be scanned through headings and short supporting blocks?
• Do spacing and type sizes show which information matters most?
• Are color and contrast helping visitors find actions and warnings?
• Does the recommendation work with the content and components you already have?
• Can you verify the change with a before-and-after screenshot or review?

A reference can be valuable even when you reject its main style. If it makes an important detail easier to notice, keep that lesson without importing the rest of the design.

Turn the comparison into changes

After the analysis, ask Gemini for a three-pass implementation brief. Pass one should address the opening hierarchy. Pass two should address repeated components such as buttons, cards, code blocks, or navigation. Pass three should refine typography, spacing, and color roles.

For every proposed change, require five fields: the problem, the affected component, the recommended adjustment, the reason it helps, and the check for completion. This gives you a manageable sequence instead of an unexplained rewrite.

Ask Gemini to preserve your product language and content. Website references can show how to organize information, but they do not establish your internal design system. If you need a more exact review, ask the agent to inspect the captured page sections, fonts, colors, spacing, and component styles separately, then combine only the findings that support your page's goal.

Use this in your AI agent

> Review the captured website references available through Fudge for a developer-focused MCP page. Compare their opening message, page structure, layout, typography, color roles, spacing, surfaces, and primary actions. Return a table of observations and tradeoffs, then recommend three implementation passes for my website. Preserve my product language, separate observed details from guesses, and do not copy brand-specific content or invent measurements that are not visible in the references. > > Install Fudge for your AI agent to bring captured design references into Gemini CLI.

Start with the decisions that affect whether visitors understand and use the page. Ask Gemini to inspect the opening section, headline and supporting copy, primary action, navigation, section order, and the way the page introduces product evidence. These choices usually matter more than a decorative detail such as a gradient or corner radius.

Next, review the repeated rules: type sizes and weights, spacing between sections, button treatments, card borders, background roles, and text contrast. Ask the agent to note where a rule repeats and where an element appears only once. Repeated choices are better candidates for shared components or style values.

A helpful sequence is: "First describe what is visible. Then explain the hierarchy. Then identify two patterns worth testing. Finally list anything that cannot be verified from the capture." This keeps the feedback grounded. Ask for a separate mobile review only when a narrow viewport or responsive state is actually available. Otherwise, have Gemini label mobile recommendations as proposals rather than observations.

Convert the comparison into a short backlog ordered by visitor impact. Put clarity and hierarchy first, repeated component rules second, and fine visual polish third. Each item should name one component or section and one outcome you can check.

For example:

• Clarify the hero copy so the tool's purpose is understood sooner.
• Reduce competing button styles to one primary action and a quieter secondary action.
• Reuse one card spacing and border rule across supporting sections.
• Set a clear type scale for headings, labels, and body text.
• Check that accent color is reserved for actions and important states.

Ask Gemini to propose one change at a time and show the expected effect before suggesting the next. If the result becomes harder to scan, keep the old version and reject that recommendation. End by asking for a concise design note that records the chosen structure, type relationships, color roles, spacing rules, and exceptions. That note helps future edits stay consistent without treating another website as your official design system.

Related questions

• Website Design Feedback MCP for GitHub Copilot
• Website design research MCP for Claude Code
• Website design feedback MCP for Claude Desktop
• Use Real Website Examples Inside Windsurf