# Website reference MCP for Cline [Open the live Fudge conversation](https://design.withfudge.com/share/website-reference-mcp-for-cline) Last updated: 2026-08-25 A website reference MCP for Cline lets you give your coding agent concrete visual examples instead of describing a design from memory. The useful workflow is simple: save a reference, inspect the parts that matter, then ask Cline to turn those observations into implementation guidance for your project. ## A practical workflow for Cline 1. **Choose two or three references with a clear purpose.** Use one reference for the overall page structure, another for typography or interaction patterns, and a third only if it adds a distinct idea. Avoid collecting unrelated inspiration. 2. **Ask for observations before code.** Have Cline identify the visible sections, content order, spacing rhythm, type hierarchy, color roles, borders, radii, shadows, and responsive changes. This gives you a checklist to review before implementation. 3. **Separate reference from imitation.** Tell Cline which qualities to borrow, such as a compact hero, restrained color contrast, or a particular card structure. Ask it to keep your own content, brand, and accessibility requirements. 4. **Implement one screen at a time.** Start with the page shell and first viewport, then check the next sections. This makes it easier to catch a wrong spacing scale or oversized heading before it spreads through the whole site. 5. **Compare the result against the references.** Review structure and visual roles, not just individual pixels. The goal is a deliberate design direction that your codebase can maintain. Open the examples below and compare the first screen before borrowing a pattern. The Notion Developer Platform, Claude Code, and Exa MCP Server references give you three different directions for thinking about developer-facing pages. Use them as visual prompts, not as proof that your page should copy any one of them. ## 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 Cline to inspect A strong request names the evidence you need: - **Page structure:** header, hero, navigation, feature sections, proof areas, forms, and footer. - **Layout:** content width, column relationships, alignment, section spacing, card dimensions, and likely mobile changes. - **Typography:** font family, available weights, heading scale, body size, line height, letter spacing, and the contrast between labels and primary copy. - **Color:** background, foreground, muted text, accent, borders, buttons, and states. Ask which colors are structural roles rather than isolated samples. - **Components:** buttons, cards, navigation, tabs, inputs, badges, and repeated patterns. - **Motion and state:** only when the reference includes visible interaction, overlays, clipping, or a meaningful transition. This produces an actionable design brief. It also makes review easier: you can check whether the implementation followed the brief rather than arguing over whether it merely feels similar. ## A simple decision framework Use the reference that best answers the current question: - **Need a developer-product page structure?** Start with the Notion Developer Platform example and study how information is grouped. - **Need a coding-agent visual direction?** Study the Claude Code example for cues about a tool-oriented product page. - **Need to explain an MCP server clearly?** Study the Exa MCP Server example for ideas about presenting technical capability without turning the page into documentation. If two references disagree, keep the pattern that supports your visitor's task. A clear explanation and readable hierarchy matter more than matching a reference's decoration. ## Turn observations into implementation work Ask Cline to return four things: a short design summary, a token list, a component map, and a build order. The token list can cover colors, spacing, type sizes, radii, borders, and shadows. The component map can identify which patterns should be reusable. The build order should begin with the page shell, then typography, then repeated components, then responsive states. Before accepting the result, check the page at the widths your visitors use, verify keyboard focus and readable contrast, and confirm that borrowed patterns still fit your content. If the result is close but inconsistent, ask Cline to compare the implemented screen with the reference again and list only the largest differences. ## Use this in your AI agent > Use my saved website references as design evidence for this Cline task. First inspect the page structure, typography, color roles, spacing, components, and visible states. Compare the references, explain which patterns are useful for my project, and separate observed details from your recommendations. Then create a concise design brief, reusable tokens, component map, responsive checklist, and implementation plan. Do not copy brand-specific content or assume unsupported behavior. [Install Fudge for your AI agent](/mcp) to use website references directly while you work in Cline. --- Give Cline a defined comparison job instead of asking it to make the page "look better." Name the references, the screen or component under review, and the decisions you need to make. > Compare these saved website references for a developer landing page. Inspect the header, hero, navigation, typography hierarchy, color roles, section spacing, card patterns, buttons, and visible responsive clues. Return a table with: observed pattern, reference, why it may work, risk of copying it, and recommendation for my project. Then propose one combined direction using my content and brand rather than reproducing any reference. After the comparison, ask for a second pass focused on implementation. Have Cline turn the chosen direction into tokens, components, and a responsive checklist. Keep the first pass descriptive and the second pass prescriptive. That separation prevents an agent from treating an attractive screenshot as a complete specification. --- Review the result in five passes. First, check hierarchy: can you identify the page purpose, primary action, and next step quickly? Second, compare spacing and alignment across sections. Third, check typography at smaller widths, including line length, wrapping, and heading scale. Fourth, verify states such as hover, focus, errors, disabled controls, and mobile navigation. Fifth, check that the copied visual direction still fits your content rather than forcing your content into another site's structure. Then ask Cline for a difference list limited to the three largest issues. A useful prompt is: > Review the implemented page against the selected references. List the three most important differences in hierarchy, layout, typography, or color. For each, explain whether it is a real problem or an intentional adaptation, then suggest the smallest code change that improves the result without copying brand-specific details. This keeps iteration focused and makes the final page easier to maintain. ## Related questions - [Use Website References in Codex with an MCP Server](/share/website-reference-mcp-for-codex) - [Website references for Claude Desktop](/share/website-reference-mcp-for-claude-desktop) - [Website Reference MCP for Claude Code](/share/website-reference-mcp-for-claude-code) - [Website reference MCP for Gemini CLI](/share/website-reference-mcp-for-gemini-cli)