# Paper MCP vs Fudge for AI coding agents

[Open the live Fudge conversation](https://design.withfudge.com/share/paper-design-mcp)

Last updated: 2026-08-25

Paper MCP and Fudge solve related but different problems for AI coding agents. Paper is strongest when the source of truth is an open Paper design file; Fudge is stronger when you need to study captured websites and saved visual references before building.

## Choose by the source of your design context

Choose **Paper MCP** when your team already works in Paper and wants an AI coding tool to read or update the currently open design file. Paper's official documentation describes a local MCP that moves design context between Paper and AI coding tools, so it fits a workflow where the design file itself is the active handoff: [Paper MCP documentation](https://paper.design/docs/mcp).

Choose **Fudge** when your reference is a public website, a saved capture, or a visual pattern you want to compare before implementation. The useful question is not simply "which MCP is better?" It is "where does the reference live, and do I need to edit it or understand it?"

Open the examples below and compare the first screen before borrowing a pattern. Raycast, boringBar, Monocle, and Cosmos are useful references for product proof, screenshot rhythm, restrained utility pages, and readable editorial layouts.

## Captured pages

[![Raycast - Your shortcut to everything](https://pin.fontofweb.com/4674?format=jpg)](https://design.withfudge.com/share/pin-4674)

[Raycast - Your shortcut to everything](https://design.withfudge.com/share/pin-4674)

[![boringBar - Taskbar Dock Replacement for macOS](https://pin.fontofweb.com/8813?format=jpg)](https://design.withfudge.com/share/pin-8813)

[boringBar - Taskbar Dock Replacement for macOS](https://design.withfudge.com/share/pin-8813)

[![Monocle for macOS - Noise-cancelling for your screen](https://pin.fontofweb.com/5622?format=jpg)](https://design.withfudge.com/share/pin-5622)

[Monocle for macOS - Noise-cancelling for your screen](https://design.withfudge.com/share/pin-5622)

[![Welcome to Cosmos](https://pin.fontofweb.com/4489?format=jpg)](https://design.withfudge.com/share/pin-4489)

[Welcome to Cosmos](https://design.withfudge.com/share/pin-4489)

## What each tool helps you do

| Job | Better fit | Why |
|---|---|---|
| Read and write the open design file | Paper | The MCP connects an active Paper file with AI coding tools. |
| Search captured websites by visual description | Fudge | The search is based on observed page details and saved references. |
| Study page sections and component structure | Fudge | You can inspect layout, sections, viewport, page state, and components. |
| Carry a defined token system into code | Paper | Paper documents tokens for color, typography, spacing, containers, breakpoints, and radius. |
| Identify the fonts and variants used by a captured page | Fudge | Font families, files, variants, sizes, weights, and line heights are available for inspection. |
| Compare several references before choosing a direction | Fudge | References can be reviewed side by side by page structure, type, color, and visual details. |

Paper's token support matters when the design system is already intentional and maintained in the file. Its documented token categories include color, typography, spacing, containers, breakpoints, and radius: [Paper design tokens](https://paper.design/docs/tokens). That makes Paper a natural choice for translating an existing design language into an implementation.

## A practical decision checklist

Use Paper first if most answers are yes:

1. Is the design already maintained in Paper?
2. Does the AI need to change that design file as part of the workflow?
3. Are the important decisions already expressed as tokens and reusable design elements?
4. Will the coding task follow the file closely rather than reinterpret outside references?

Use Fudge first if most answers are yes:

1. Are you collecting inspiration from shipped websites or product pages?
2. Do you need to compare page structure, typography, color, spacing, and responsive details?
3. Are you unsure which reference is closest to the product you are building?
4. Do you want observed details that can guide CSS, Tailwind v4, JSON, or DESIGN.md work?

The two tools can also sit in sequence. Review and compare outside references first, select the patterns worth keeping, then use Paper when those decisions have been formalized into an editable design file and token set. That avoids treating a screenshot as if it were already a complete design system.

## Bottom line

For **design-file collaboration**, start with Paper MCP. For **reference research and reverse-engineering captured interfaces**, start with Fudge. If your process includes both exploration and formal design handoff, use the tools for their strongest jobs: Fudge helps you decide what to borrow, while Paper helps keep the chosen system organized and editable.

## Use this in your AI agent

> Compare Paper MCP and Fudge for this project. First identify whether my source of truth is an editable Paper design file or a set of captured website references. If it is Paper, preserve the documented token categories and explain how they map into the implementation. If it is a website reference, list the page structure, typography, colors, spacing, and responsive decisions worth borrowing, then separate observed details from assumptions. Recommend one workflow and give me a short implementation checklist.

[Install Fudge for your AI agent](/mcp)

---

Yes. A sensible sequence is to use Fudge during exploration and Paper during formalization.

Start by collecting a small reference set: one or two captured websites, a page with a useful navigation pattern, and any typography or color direction you want to test. Compare the references by structure and observed details rather than copying a whole page. Keep a short decision list: preferred type scale, spacing rhythm, surface treatment, button shape, and responsive behavior.

Then move the selected direction into Paper if you need an editable design file that an AI coding tool can read or update. Define the decisions as tokens where appropriate, including color, typography, spacing, containers, breakpoints, and radius. The result is clearer than asking an agent to infer a complete system from a screenshot.

Use Paper as the maintained design handoff and Fudge as the reference-checking step. If a later implementation feels too close to one source, return to the captured references and compare the specific page details that influenced the decision.

---

Give the agent a constrained brief that names the source, the decisions it may reuse, and the decisions it must make itself. For a Paper-led workflow, ask it to inspect the active file, preserve the token categories, identify reusable components, and map the design into the existing code structure. Ask it to flag missing states instead of inventing them silently.

For a Fudge-led workflow, ask it to compare two or three captured references, extract only observed details, and turn them into an implementation checklist. Require separate sections for layout, typography, color, spacing, interaction states, and responsive behavior. Ask for confidence notes where the reference does not reveal an interaction or mobile state.

In either case, finish with a review pass: check the first screen, navigation, key action, text hierarchy, contrast, and small-screen behavior. The agent should explain which choices came from the source and which choices are new product decisions.

## Related questions

- [Paper MCP alternatives for website design research](/share/paper-design-mcp-alternative-for-website-design-research)
- [Paper Alternative with Design System Export](/share/paper-design-alternative-with-design-system-export)
- [Paper Design vs Fudge for design references](/share/paper-design-vs-fudge-for-design-references)
- [Palate MCP alternative for website design research](/share/palate-mcp-alternative-for-website-design-research)