MCP returns fallback code instead of Code Connect output for large instance subtrees #417

Summary

Figma MCP (get_code_connect_map and get_design_context) stops returning a component's Code Connect template result once the selected instance has many connected descendants. It returns a fallback instead. Dev Mode shows the correct template result for the same node at the same time. MCP gives no error and no "lookup timed out" notice.

The parent template only returns a marker containing the instance name. It does not inspect or execute any children.

In a minimal reproduction made from generic components in a fresh file (no team library involved), we saw a consistent boundary:

• the template result is returned with 142 connected instances under the selected node;
• a fallback is returned from 143 connected instances.

This is an observation from our reproduction; we have not found any documentation of such a limit.

Environment

• @figma/code-connect 2.0.2, parserless templates (*.figma.ts)
• Components and instances in the same file (no library publish needed to reproduce)
• Figma remote MCP server (https://mcp.figma.com/mcp), called from Claude Code
• Observed on 2026-10-24

Reproduction

Components

Every component has a Code Connect template, and slot contents are filled per instance.

Templates

Replace the URL in each template with the link to its corresponding component. Give each component its own template ID.

Table: a fixed string only.

// url=<link to the corresponding Figma component>
import figma from 'figma';
const instance = figma.selectedInstance;
export default {
  id: 'Table',
  imports: [],
  example: figma.code`// PROBE-R v1 · ${instance.name}`,
  metadata: { nestable: false },
};

The child templates return simple tags and do not execute other templates. For example, Cell uses:

// url=<link to the corresponding Figma component>
import figma from 'figma';
const instance = figma.selectedInstance;
const label = instance.getString('label');
export default {
  id: 'Cell',
  imports: ["import { Cell } from './Cell'"],
  example: figma.code`<Cell>${label}</Cell>`,
  metadata: { nestable: true },
};

Steps

1. Publish the templates with figma connect publish.
2. Place Table instances whose row and header counts give different numbers of connected instances. The count includes the root and fixed sublayer instances. With six cells per row, 19 rows and eight headers give 142 instances including the table itself: 1 + 19 + 19 × 6 + 8. Adding one header gives 143.
3. For each instance, select it in Dev Mode, and call get_code_connect_map and get_design_context with its node ID.

Results

get_code_connect_map: we judged each result only by whether the PROBE-R v1 mark is present in the root entry's snippet.

What the fallback looks like:

• get_code_connect_map: the root entry keeps hasTemplate: true. Its snippet is a tag named after the layer, snippetImports is [], and snippetNestedFunctions contains one Tailwind design-code function. Every descendant entry still has its normal template snippet.
• get_design_context:
  • In the minimal reproduction, the CodeConnectSnippet for the root contains an auto-generated <Table body="…" head="…"> with child tags instead of the template result.
  • In our production design system (a library used from another file), the response was Tailwind design code with no CodeConnectSnippet at all.

Other observations in the minimal reproduction:

• The same 142/143 boundary appeared when fixed icon instances were included in the count, even though those icons were absent from the map. A table of IconCells with 82 map entries (142 instances including the fixed Icon sublayers) succeeded, and one with 83 map entries (143 instances) fell back.
• Adding plain layers did not trigger the fallback in our tests. A table with 63 connected instances and 1,086 nodes in total succeeded.
• A larger response still succeeded. A 140-instance table whose cell templates produce 400 characters each (an 83 KB response) returned the template result.
• The boundary did not move in any of these cases:
  • adding up to 60 instances without templates;
  • nesting instances up to 5 levels deep;
  • adding hidden connected instances, in each of four ways: a boolean property defaulting to off, visible = false in the definition, a property turned off on the instance, and a layer hidden directly on the instance.
• A failed request completed in 6.9 seconds, while a successful request took 11.0 seconds. Total request duration alone therefore does not explain the fallback; a timeout within an internal stage remains possible.

Expected

MCP returns the same template result that Dev Mode shows. If MCP hits a limit, the response should say so, as the "Code Connect lookup timed out" notice does. Then clients can tell "not connected" apart from "lookup incomplete". Today the fallback looks like a normal snippet.

Questions

1. Is there a limit on how many connected instances MCP resolves under one selected node? What exactly does it count (for example, hidden instances of library components), and is it documented?
2. Can a client request only the selected node's template result, without resolving Code Connect output for its descendants?
3. Could the fallback be marked explicitly, for example with a flag on the entry or a notice in the response?

Related: #407 ("Code Connect lookup timed out" on wide nodes).