Website Design System MCP for Gemini CLI

Use website references with Gemini CLI to inspect layouts, fonts, colors, and spacing, then turn the findings into a practical design brief and implementation plan.

website design system mcp for gemini cli

Contents

  • [Choose references for a real design question](#choose-references-for-a-real-design-question)
  • [Turn observations into a design brief](#turn-observations-into-a-design-brief)
  • [Give Gemini CLI a bounded implementation request](#give-gemini-cli-a-bounded-implementation-request)
  • [Check structure, states, and mobile behavior](#check-structure-states-and-mobile-behavior)
  • [Use this in your AI agent](#use-this-in-your-ai-agent)

Gemini CLI can work from website design references when the references are captured and their useful details are available through an MCP connection. The practical workflow is to collect a small reference set, inspect only the details relevant to your task, turn observations into a design brief, and ask Gemini CLI to apply that brief to your existing code.

Choose references for a real design question

Start with one or two strong references instead of a large inspiration folder. Choose pages that match the job you are doing, such as a product landing page, documentation site, dashboard, or developer tool. The examples below include Notion Developer Platform, Claude Code, and Exa MCP Server. They can help you discuss developer-focused presentation patterns, but they are visual starting points, not ready-made design systems for your product.

Before inspecting them, write down the question you want answered. You might want to compare navigation density, understand how a developer product presents code, or find a useful relationship between headline size and supporting text. A specific question keeps the resulting brief short and makes it easier to reject irrelevant details.

Captured pages

Turn observations into a design brief

Break each reference into decisions Gemini CLI can use:

  1. Page structure: header, navigation, hero, feature sections, code areas, testimonials, pricing, and footer.
  2. Layout: content width, column proportions, section spacing, alignment, and mobile changes.
  3. Typography: font family, size, weight, line height, casing, and the difference between display and body text.
  4. Color roles: page background, surface, primary text, muted text, accent, border, success, and warning colors.
  5. Components: buttons, cards, inputs, code blocks, tabs, badges, and navigation states.
  6. Details: radii, borders, shadows, gradients, image crops, and hover or active treatments.

Then write a brief with three layers. First, describe the visual direction in plain language, such as "quiet developer tooling, dense but readable, warm off-white surfaces, restrained blue accents." Second, list measurable choices: maximum content width, spacing steps, heading scale, body size, corner radius, border color, and button height. Third, define the rules that must remain consistent, such as one button height, one code-block treatment, and a predictable mobile reading order.

Mark every line as observed, adapted, or newly recommended. An observed line describes what the reference visibly does. An adapted line explains how you are changing it for your product. A recommended line is a new decision. This prevents Gemini CLI from treating an inspiration site's exact choices as requirements.

Give Gemini CLI a bounded implementation request

Ask for a plan before requesting code. Include the page to change, the design rules, the components that already exist, and the checks Gemini CLI should perform. A strong request might say:

> Use the attached design brief to update the landing page. Keep the existing content and routing. Apply the spacing, typography, surface, border, and button rules consistently. Reuse existing components where possible. Check desktop and mobile layouts, keyboard focus states, text wrapping, and contrast. Summarize which files changed and list any design decisions that were not directly specified.

If you want an observed reference turned into implementation notes, ask for a Tailwind v4, CSS, JSON, or DESIGN.md version first. Review that output before asking Gemini CLI to edit production code. For the first edit, choose one representative section and ask the agent to report the files changed, reusable rules introduced, and assumptions made.

After rendering the result, compare the system rather than isolated pixels. Look for repeated spacing, consistent button heights, shared card borders, predictable heading sizes, and one clear treatment for code or technical content. If similar elements look different, ask Gemini CLI to consolidate the rules before polishing individual details.

Check structure, states, and mobile behavior

Use three passes after the implementation:

  • Task flow: confirm that navigation, links, forms, content, and existing behavior still work.
  • Design consistency: check repeated type, spacing, surfaces, borders, buttons, cards, and code blocks.
  • Readability: tab through the page, inspect focus visibility, resize the viewport, test long headings and error messages, and review muted text on every surface.

Also verify that mobile keeps the important action visible and preserves a sensible reading order. Ask the agent to explain what stacks, scrolls, hides, or changes order. A reference is useful only when the resulting page still serves your product and remains understandable without the reference beside it.

Use this in your AI agent

> Inspect the selected website references and create a concise design brief for this Gemini CLI project. Extract page structure, typography, color roles, spacing, borders, radii, shadows, gradients, and component patterns. Separate observed details from recommendations. Then update the target page using the existing components, preserve its content and behavior, check desktop and mobile layouts, and report the files changed plus any assumptions.

Install Fudge for your AI agent.

How should I structure the design brief so Gemini CLI applies it consistently?

Use a small token table followed by component rules and page-level rules. Keep it specific enough to implement, but short enough that the agent can hold the whole system in context.

Start with tokens: content width, spacing scale, body size, heading sizes, line heights, radii, border color, surface colors, text colors, and accent colors. Give each token a role, not just a raw value. For example, describe a color as "muted text on light surfaces" rather than only listing a hex value.

Next, define component rules. State the height and padding for buttons, the surface and border treatment for cards, the style of code blocks, and the difference between primary and secondary actions. Add interaction rules for hover, focus, disabled, and error states.

Finish with page rules. Describe the order of sections, the maximum width, the main alignment, the mobile stacking order, and which action should remain prominent. Mark each line as observed, adapted, or newly recommended. That label helps Gemini CLI avoid treating an inspiration site's exact choices as requirements.

Ask the agent to reuse existing components and to list assumptions before making broad changes. Review the brief as a standalone document before using it for implementation.

What should I check after Gemini CLI builds the page from the reference?

Check the result in three passes. First, verify structure and behavior: navigation works, links go to the right place, forms still submit, content is complete, and mobile sections appear in a sensible order. A visually similar page is not useful if the original task flow has changed.

Second, compare the system rather than isolated pixels. Look for repeated spacing, consistent button heights, shared card borders, predictable heading sizes, and one clear treatment for code or technical content. If similar elements look different, ask Gemini CLI to consolidate them into shared rules instead of fixing each element separately.

Third, test states and readability. Tab through the page, inspect focus visibility, resize the viewport, check long headings and error messages, and review muted text on every surface. Confirm that images and gradients do not hide important text or controls.

Ask for a short change report containing files changed, reusable tokens introduced, components reused, and assumptions made. Compare that report with your brief. If the implementation added many one-off values, send the agent back to the design rules before polishing individual sections.

Related questions