Better code, fewer tokens: The benefits of Code Connect in MCP

Why coding agents keep rebuilding what you already built

Agentic coding tools have gotten remarkably good at turning a design mock into working UI. What they have not gotten good at is knowing which components your team already maintains. Given only a visual representation of a design, an agent will happily reconstruct a stepper from progress bars or hand-build a tab bar from raw divs and CSS — output that looks right in a screenshot but is wrong for your codebase.

Code Connect in Figma's MCP server is designed to close that gap. When Figma components are mapped to real production components via Code Connect templates, the MCP server's get_design_context tool substitutes those production-accurate snippets into its response, giving the agent literal import statements and property values from your design system instead of a generic React interpretation of the canvas.

We built an eval harness to quantify the difference. Running identical design-to-code tasks against the Figma MCP server — with and without Code Connect templates — produced clear median improvements across 27 test cases:

• Token usage: down 29.5%
• Task duration: down 19.6%
• Code quality: up one full point, from 2 to 3 on a 1–4 Likert scale

What the agent sees without Code Connect

Without Code Connect, the MCP server describes the design as generic React. The description is visually accurate, but the agent has no mapping from that visual structure to your actual codebase. In practice, three failure modes surface: the agent invents a component from scratch, picks the wrong component from your design system, or eventually finds the right component only after burning tokens on exploration.

The raw React output the agent receives is verbose and ambiguous for production purposes:

<div role="tablist" className="flex gap-1 rounded-md bg-gray-100">
  <button className="bg-white shadow rounded">Design</button>
  <button className="text-gray-600">Code</button>
</div>

With Code Connect templates in place, that same response carries a snippet that references your actual design system components:

<SegmentedControl value="design" options={["Design", "Code"]} />

The agent no longer needs to guess. It is handed the correct component name, the correct import path, and the correct property values — its job reduces to placing that code where it belongs.

How we ran the eval

Our harness ran design-to-code tasks through the Figma MCP server twice: once with Code Connect enabled and once without. We used two React-based design systems — SDS (Figma's example system, where nearly all components have Code Connect) and FPL (our larger internal system, where coverage is patchier at around 6% of MCP responses). LLM judges scored the output code against known-good implementations using five criteria: correctness, code quality, maintainability, completeness, and best practices, each on a 1–4 scale. We ran the eval with both Claude Sonnet 4.5 and Claude Opus 4.7; some runs with complex designs took over 24 hours to complete with all variants.

Coverage drives the gains

The median numbers hide a strong correlation: the single biggest factor in improvement was Code Connect coverage. That is a function of both how much of the handoff design consists of design-system components and how many of those components actually have Code Connect mappings. Where coverage is high and components map cleanly between design and code — as with SDS — agents make fewer exploratory tool calls and spend less time grepping for component and icon names.

The contrast was stark in one representative pattern-library case. Agents without Code Connect inspected node_modules, ran broad namespace greps, and in several runs hand-built the tab bar from scratch, churning on custom CSS along the way. With Code Connect, the agent reached directly for the real Tabs and Button components, finishing in roughly 77% of the time and 62% of the tokens.

Code quality differences were equally pronounced — and not just in terms of style. In one run without Code Connect, the hand-built tabs were not even interactive; the selected state was hardcoded to match the design, and icon and padding details drifted subtly from the source. The run with Code Connect imported and used the actual design-system components, producing more succinct code that matched the intended behavior.

{/* Plain divs for the tabs */}
<div className="lv-tabs">
  <div className="lv-tab lv-tab-inactive"><span className="lv-tab-text-inactive">File</span></div>
  <div className="lv-tab lv-tab-active"><span className="lv-tab-text-active">Assets</span></div>
</div>

…

{/* Raw button element */}
<button className="lv-browse-btn">
  <span className="lv-browse-btn-text">Browse team libraries</span>
</button>

…

/* CSS: ~300 more lines*/
.lv-tab { display: flex; align-items: center; gap: 4px; height: 24px; padding: 0 8px; border-radius: var(--radius-medium, 5px); }
.lv-tab-inactive { background: var(--color-bg, white); }

With Code Connect, that same task resolved to imports of real components and significantly less code:

{/* Usage of the FPL tab component */}
const [tabPropsMap, tabPanelPropsMap, tabManager] = Tabs.useTabs<'firstTab' | 'secondTab'>(
  { firstTab: true, secondTab: true },
  { defaultActive: 'secondTab' },
)

<Tabs.TabStrip manager={tabManager}>
  <Tabs.Tab {...tabPropsMap.firstTab}>File</Tabs.Tab>
  <Tabs.Tab {...tabPropsMap.secondTab}>Assets</Tabs.Tab>
</Tabs.TabStrip>

…

{/* Usage of the FPL Button component */}
<Button variant="primary" width="fill" onClick={() => {}}>
  Browse team libraries
</Button>

Context is the missing ingredient

An LLM has no inherent idea of what “good” code looks like inside your organization. Unless you supply that context, an agent will burn tokens hunting through your design system for the right component — or, just as likely, decide it’s faster to reinvent the wheel. The visual result may pass muster, but the underlying code is not something you want merged into your repository. Agents need explicit, structured guidance: a concrete snippet showing exactly how a component is meant to be implemented in your codebase.

For teams already running the Figma MCP server, extending Code Connect across more of your design system is the practical next step. It shortens the path from design to code, lowers token spend, and produces output that consistently matches your engineering standards. The quickstart guide covers how to wire up additional components.