Website design feedback MCP for Claude Desktop

Use website references with Claude Desktop to get practical feedback on layout, typography, color, spacing, and component choices before you revise a page.

website design feedback mcp for claude desktop

Contents

  • [Start with a specific review job](#start-with-a-specific-review-job)
  • [What useful feedback looks like](#what-useful-feedback-looks-like)
  • [A practical scoring method](#a-practical-scoring-method)
  • [Use this in your AI agent](#use-this-in-your-ai-agent)

For website design feedback in Claude Desktop, use references as evidence for a focused review, not as a request for a vague visual opinion. The strongest workflow is to give Claude captured examples, ask it to compare your page against them, and turn the observations into a short list of changes you can test.

Start with a specific review job

Decide what you want feedback on before you provide references. A useful review might ask whether the first screen explains the product clearly, whether a developer page is easy to scan, whether the type scale creates a clear hierarchy, or whether a feature grid gives every card equal weight. Avoid asking for "better design" because it encourages broad, hard-to-check suggestions.

Use one reference for the main question and one or two supporting references for comparison. The examples below include Notion Developer Platform, Claude Code, and Exa MCP Server. Compare their visible choices and ask which ones help a visitor find information or decide what to do next. Do not assume that a pattern works simply because it appears on a polished page.

A good first request is:

> Review my page against these website references. Describe what is visible before suggesting changes. Focus on hierarchy, section order, content width, typography, color roles, spacing, borders, shadows, buttons, and responsive clues. Separate observations from recommendations, and rank the recommendations by visitor impact.

Captured pages

What useful feedback looks like

Useful feedback is concrete enough to act on. "The hero feels weak" is not enough. "The headline wraps to four lines, the supporting paragraph is nearly as wide as the page, and three buttons compete for attention" gives you a testable diagnosis.

Ask Claude to return feedback in four groups:

  1. Keep: choices that already support the page's goal.
  2. Change: problems that make the page harder to understand, scan, or use.
  3. Test: changes worth trying but not treating as certain.
  4. Ignore: reference details that do not fit your product, audience, or content.

For each recommendation, request the affected section, proposed change, reason, and expected visitor benefit. This keeps a style preference from being mistaken for a usability problem.

Review the page in layers. Start with structure: can a visitor tell what the page is about, who it is for, and what action to take? Next review hierarchy: do headings, labels, paragraphs, and buttons have distinct roles? Then review spacing and grouping: related content should feel connected, while separate tasks should not blur together.

After that, check visual details such as font family and weight, line height, letter spacing, color contrast, border strength, corner radius, shadow softness, gradients, and image crops. These details matter, but they should support the structure rather than distract from it. Finally, review states and screen sizes. A reference with an open menu, selected tab, hover state, or desktop-only layout may not describe the default experience.

A practical scoring method

Score each section from 1 to 5 on four questions: clarity, priority, scanability, and consistency. Add a short reason for every score. Fix the lowest score that affects the visitor's next decision, then score the page again. Do not redesign every section at once. One improved hero or navigation system can reveal whether the rest of the page still needs work.

Keep a decision log with three columns: observation, action, and result. This lets you remove changes that did not help and keeps the review grounded in what visitors can actually see. Compare captured references side by side before asking Claude to recommend a change, so the review starts from visible examples rather than memory.

Use this in your AI agent

> Give design feedback on my current website using the attached captured references. First describe the current page and the reference patterns separately. Then score my page from 1 to 5 for clarity, priority, scanability, and consistency, with one reason per score. Recommend the three highest-impact changes, explain why each fits my audience, and identify any reference detail I should not copy. After I approve the direction, implement one section at a time and preserve my content, brand identity, and responsive behavior.

Use Fudge with your AI agent to make captured references available during the review.

How can I get more specific design feedback from Claude Desktop?

Give Claude a bounded question, a page state, and a requested output format. For example, ask it to review only the navigation and first screen at desktop width, then return five observations, three risks, and two recommended changes. Include the visitor action you care about, such as starting a trial, finding documentation, or understanding an integration.

Ask for evidence in plain language: headline line count, content width, number of visible actions, section spacing, contrast between text levels, and the order in which information appears. If you have a mobile capture, ask for a separate comparison rather than assuming desktop rules scale down well.

You can also ask Claude to challenge its own recommendations: "What would make this change a poor fit for my page?" That helps separate a useful pattern from a personal taste preference. Keep the references focused. Three examples with different jobs are usually more informative than a large collection with no comparison question.

What should I do after Claude gives me website design feedback?

Turn the feedback into a small experiment. Choose the recommendation that affects the visitor's next decision most directly, write down the current behavior, and define what will change. For example: reduce the hero to one primary action, narrow the paragraph measure, and make the supporting link visually quieter.

Implement that section first, then inspect it at the same screen sizes and content length used in the review. Check whether the headline still wraps well, whether the action is easy to find, whether the section remains distinct from the next block, and whether the page still feels like your product. Record the result as helped, neutral, or worse, with a short reason.

If the change helps, move to the next lowest-scoring section. If it does not, ask Claude to explain which assumption failed and suggest a smaller alternative. Avoid stacking several untested changes because you will not know which one improved or weakened the page. The goal is a repeatable review cycle, not a single dramatic redesign.