# Website Design Feedback MCP for Codex [Open the live Fudge conversation](https://design.withfudge.com/share/website-design-feedback-mcp-for-codex) Last updated: 2026-08-25 A website design feedback MCP for Codex lets your coding agent use captured website references while it reviews or builds a page. The useful workflow is to give Codex a target page, a few references, and a specific decision to make, then ask for feedback tied to visible design details. ## A practical workflow for Codex 1. **Collect references that match the job.** Choose examples for the same type of page, such as a developer landing page, documentation site, pricing page, or product onboarding screen. Save references that show the interaction or layout you want to study, not only attractive homepages. 2. **State the decision.** Ask whether your hero has enough visual priority, whether the type scale supports scanning, or whether the call to action is easy to find. A broad request such as "make this look better" usually produces less useful work. 3. **Ask for observed details first.** Have Codex identify sections, layout relationships, typography, color roles, spacing, borders, radii, shadows, images, and visible states before it recommends changes. 4. **Request a small implementation plan.** Ask for the three changes with the highest likely impact, including the files to edit and the reason for each change. 5. **Review the page again.** Compare the updated page with the references and ask Codex to identify what improved, what drifted, and what still needs a human decision. Open the examples below and compare the first screen before borrowing a pattern. The Notion Developer Platform reference is useful for studying a compact developer-focused page. Claude Code and Exa MCP Server are useful comparison points for pages that explain technical tools and invite developers to try them. Treat these as design references, not as proof that any particular structure is right for your product. ## 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 ask Codex to check Use a checklist so the feedback stays concrete: - Does the first viewport communicate what the product does and who it is for? - Is there one clear primary action, with secondary actions visually quieter? - Do headings, supporting text, and controls form a readable hierarchy? - Are sections separated by spacing, background changes, borders, or other visible signals? - Do card widths and gaps create a consistent rhythm? - Are colors assigned to roles such as page background, text, muted text, accent, border, and status? - Are font families, weights, sizes, and line heights used consistently? - Does the layout still work when headings wrap or content becomes longer? - Are interactive states, overlays, clipping, and motion understandable from the page itself? Ask for evidence in the form of a location and an observation: "The hero heading occupies two lines and the button sits below the supporting copy" is more actionable than "the hero feels balanced." ## A simple decision framework Prioritize changes in this order: 1. **Clarity:** Can a visitor understand the page and its next action quickly? 2. **Hierarchy:** Does the visual weight match the importance of each message? 3. **Consistency:** Do spacing, typography, colors, and components follow repeatable rules? 4. **Polish:** Do borders, shadows, gradients, imagery, and motion support the hierarchy? If clarity is weak, do not begin with shadows or decorative gradients. If hierarchy is strong but the page feels unfinished, inspect type variants, spacing, borders, radii, and color contrast. If the page looks close to a reference but feels unlike it, compare the underlying relationships rather than copying isolated values. A strong Codex request might ask it to inspect the captured references and the current page, compare the hero hierarchy and section rhythm, identify the largest three differences, and return a short implementation plan. You can then ask for code only after agreeing with the diagnosis. This keeps design feedback separate from unreviewed edits and makes each change easier to test. ## Use this in your AI agent > Review my current website against the saved references for developer tools. First list observable differences in page structure, hero hierarchy, typography, colors, spacing, and component styling. Then recommend the three highest-impact changes, explain why each matters, and give me a small implementation plan for Codex. Do not copy branding or content; use the references only to guide reusable layout and design decisions. [Install Fudge for your AI agent](/mcp) --- Give Codex a narrow comparison task and define the output you want. For example: > Compare my landing page with the saved Notion Developer Platform, Claude Code, and Exa MCP Server references. Focus only on the first viewport, heading hierarchy, primary action, section spacing, card structure, and typography. For each difference, describe what is visible, where it appears on my page, and whether it is a clarity, hierarchy, consistency, or polish issue. Finish with the three changes that would most improve the page, without writing code yet. After reviewing the response, ask for a second pass on the two changes you accept. Include your actual goal, audience, and primary action so Codex does not treat visual similarity as the only measure of success. A reference can suggest a useful relationship, but your content length, product category, and conversion path may require a different implementation. --- Provide the current page URL or project context available to your agent, the page goal, the intended visitor, and the one action you want visitors to take. Add two or three saved references and label what each one contributes, such as developer-focused hierarchy, technical product explanation, or compact card layout. Also include constraints that affect the decision: required sections, existing components, brand colors, supported screen sizes, and whether the page must preserve current content. Ask Codex to inspect before editing, then request a change list with file locations and a way to verify each result in the browser. A useful final check is: "After editing, compare the updated page with the same checklist and report any remaining problems." That keeps the work focused on visible outcomes instead of allowing a large refactor to hide whether the page actually became clearer. ## Related questions - [Website Design Feedback MCP for Cursor](/share/website-design-feedback-mcp-for-cursor) - [Use Real Website Examples Inside Windsurf](/share/real-website-examples-inside-windsurf) - [Website design research MCP for Claude Code](/share/website-design-research-mcp-for-claude-code) - [Website design feedback MCP for Cline](/share/website-design-feedback-mcp-for-cline)