# Website design research MCP for Codex [Open the live Fudge conversation](https://design.withfudge.com/share/website-design-research-mcp-for-codex) Last updated: 2026-08-25 If you want Codex to use real website design references, an MCP server gives it a way to search saved examples and inspect the details behind them. The useful workflow is: collect references, compare the parts that matter, then ask Codex to turn those observations into code for your project. ## A practical workflow for Codex 1. **Start with a small reference set.** Choose two to five websites that match the job you are doing, such as a developer landing page, documentation site, dashboard, or pricing page. Avoid collecting dozens of unrelated examples. 2. **Search by what you need to copy carefully.** Ask for references with descriptions such as "developer product page with a quiet hero and dense documentation navigation" or "dark dashboard with compact cards and bright status colors." 3. **Inspect one page at a time.** Check its sections, viewport, layout, typography, colors, spacing, borders, radii, shadows, imagery, and visible states. 4. **Compare before coding.** Separate recurring patterns from one-off decoration. A pattern that appears across several references is a stronger candidate for your own interface. 5. **Give Codex constraints.** Tell it your framework, existing components, content, breakpoints, accessibility needs, and which details should be adapted rather than copied. Open the examples below and compare the first screen before borrowing a pattern. Notion Developer Platform, Claude Code, and Exa MCP Server make a useful set because they represent developer-facing product pages with different amounts of copy, navigation, and visual density. ## 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 inspect For structure, ask it to list the page sections in order and describe the purpose of each one. For typography, ask for the font families, available weights, sizes, and line heights used in headings, body copy, labels, navigation, and code-like text. For color, ask it to separate background, text, border, accent, success, warning, and interactive roles instead of returning only a list of hex values. For implementation, ask for the measurements that affect decisions: maximum content width, column relationships, card spacing, button height, corner radius, border treatment, shadow softness, and responsive changes. Then ask Codex to map those observations to your existing design tokens. This avoids a page that looks close in one viewport but breaks when the content grows. ## A simple comparison checklist Use a table with one row per reference and these columns: - Hero structure: centered, split, editorial, or product-led - Navigation: compact, expanded, sticky, or layered - Content width and column count - Heading scale and body measure - Primary action placement and shape - Surface treatment: flat, bordered, elevated, or tinted - Image or product-preview role - Mobile changes that are visible in the capture - Details worth adapting - Details to leave behind The last two columns matter most. "Use a two-column hero with a product preview" is actionable. "Make it feel modern" is not. Ask Codex to produce a short implementation plan before it edits files, including which existing components it will reuse and which values it will add as tokens. ## Keep research separate from ownership A reference inspection tells you what is visibly present in a captured page. It does not prove that you own the original design system, source files, brand assets, or exact implementation. Treat the result as design research: adapt the hierarchy, spacing logic, interaction idea, or visual relationship, then create your own content and styling. A good final check is to compare your implementation against the reference at the same viewport, then test a narrow viewport and longer content. Look for hierarchy, readability, focus states, and overflow, not just surface resemblance. If the result only works with the reference copy and image proportions, the research has not yet become a durable interface. ## Use this in your AI agent > Use the connected website design references to research a developer landing page for my Codex project. Compare the relevant examples, inspect section structure, typography, colors, spacing, borders, radii, shadows, and responsive behavior, then recommend an original implementation using my existing components and tokens. Show a concise comparison table first, list what to adapt and what to avoid copying, and finish with a step-by-step coding plan. Do not invent details that are not visible in the references. [Install Fudge for your AI agent](/mcp) to use this workflow from Codex. --- Include five things: the product you are building, the exact screen you need, the references Codex should compare, the implementation constraints, and the format of the answer you want. A useful prompt says: "Research these captured developer websites for a new onboarding page. Compare the hero, navigation, content width, typography hierarchy, buttons, cards, and mobile changes. My app uses React, Tailwind, and an existing Button and Card component. Keep the visual direction original, reuse current tokens where possible, and return a comparison table, recommended decisions, open questions, and an implementation plan before changing code." Also state what Codex must not assume. Ask it to distinguish visible observations from recommendations, avoid copying brand-specific wording or assets, and mark anything it cannot verify from the references. If you need code, request one small implementation step at a time. That makes it easier to review whether the result matches the design decisions instead of accepting a large rewrite based on vague similarity. --- Turn the research into decisions, not a scrapbook. Start with a one-sentence goal, such as "Help developers understand the product and reach the setup action quickly." Then record the chosen page structure, content order, responsive rules, type hierarchy, color roles, surface styles, and interaction states. For each decision, include a reason and a constraint. For example: "Use a split hero because the product preview needs room beside the explanation; collapse to one column below the narrow breakpoint; keep the action visible after the heading." Add a short list of rejected alternatives so Codex does not reopen settled choices. Finish with acceptance checks: the page should work with longer headings, keyboard focus should remain clear, text should remain readable against surfaces, cards should not overflow on small screens, and the main action should be easy to locate. Give Codex this brief alongside the reference comparison and ask it to implement only the first section. Review that result before expanding the page. ## Related questions - [Website design research MCP for Cursor](/share/website-design-research-mcp-for-cursor) - [Website design feedback MCP for Windsurf](/share/website-design-feedback-mcp-for-windsurf) - [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)