Experimental feature: Allow the LLM to automatically prune and read large data.

[fightZy]

Modifications:

1. Add a data size reading interface.
2. Allow reading multiple nodes at once.
3. Dynamically inject a tool prompt to guide the LLM to prune and read data when encountering sizes exceeding the specified limit.

Core Objective of the Prompt:
Guided by the "pruning" concept, the Agent decomposes data reading top-down. If a node's size exceeds the limit, it reads only level-1 data (self-properties and child node information), then applies the same rule recursively to child nodes until completion.

Experimental Results:
Advantages:

• Significantly improves the experience of reading large datasets, directly avoiding exceptions caused by bulk data retrieval.

Disadvantages:

1. Lengthy Process: Cannot complete all tasks in one go. For example, restoring a design稿 to code in Cursor requires multiple rounds of dialogue to progress step-by-step.
2. Context Overflow: After multiple dialogue rounds, data exceeds the context window, causing the LLM to forget prior information.

Improvement for Disadvantage 2:
Enable the Agent to automatically maintain a task document record.md to log all task-related content or to-dos. Each dialogue starts with reading record.md.

My Experimental Input in Cursor:

@App.tsx  
Gradually restore the design to code on this page  
@figma url  

After fetching data, read, record, and update the todo list in the document, including any to-dos and task progress for the current task. Record Figma node IDs when specifying data for easy lookup @record.md  

Usage:
Specify the maximum data retrieval limit per request via env GET_NODE_SIZE_LIMIT (unit: KB):

"Framelink Figma MCP": {  
  "command": "<command>",  
  "args": [  
    <...args>  
  ],  
  "env": {  
    "GET_NODE_SIZE_LIMIT": 150  
  }  
},  

The scenarios of my self-experimentation may be relatively limited, and everyone is welcome to try the experiment and provide suggestions.

[GLips]

Nice! This is extremely promising. The LLM did a pretty great job with a multi-frame app mockup I've got.

I'm going to review the code more closely but this is working great. Very exciting.

One thing I think we'll want to do is refine the prompt a bit to make sure the LLM follows the instructions. Specifically, I found that Claude Sonnet 4 (which I was testing with) wanted to get ALL the data before implementing anything, which kinda defeats the purpose of the pruning strategy.

Updating the prompt helped it work more iteratively—grabbing one screen's design first and in full, implementing it, then moving on to the next frame. Still have a bit more refining and testing to do there but I love this. Nice work!

Will be back a bit later with more thoughts on any code organization or the like.

[fightZy]

Yes, in my experiment, the LLM does not 100% follow the prompt to obtain data step by step. My current approach is to prompt the LLM through response error messages, as I am doing in the code. Of course, it would be better if we can optimize the prompt! Looking forward to more of your sharing!

[fightZy]

I’ve tested the latest prompt and think it’s already excellent and crystal-clear. However, I still think there are some points worth discussing.

In my testing:

1. The first-step behavior varies significantly across models, manifesting in three scenarios:
   1. get_figma_data_size;
   2. get_figma_data (full data);
   3. get_figma_data with the depth: 1 parameter.

Model	First-Step Behavior
Claude 4	Predominantly 2, with occasional 1s.
Claude 4-thinking	Mostly 1, with a few instances of 2.
Gemini-2.5-pro	All three scenarios occurred, with 1 and 3 dominating.
GPT-4.1	All three scenarios occurred, primarily 1 and 3.

In summary: Performance across models is unstable, and scenario 3 is undesirable.

2. The iteration steps may not follow expectations. When handling oversized data, after retrieving data size and using depth: 1, Claude 4-thinking often tries to fetch full data again. Most models also attempt to read multiple child nodes simultaneously, rather than following the prompt’s "depth-first" instruction.

Based on this, I further optimized the prompt::
1.Enhanced the data size limit prompt, leading most models to start with get_size as the first step.
2.Replaced "screen/component" with the more universal term "node," resulting in more stable model performance.
3.Emphasized selecting from child nodes to avoid attempting to retrieve full-volume data from parent nodes..

prompt content, I look forward to your guidance when you have time to review it again. @GLips

## Figma Data Size Guidelines
- **Over ${sizeLimit}KB**: with \`depth: 1\` to get structure only, enter the *Pruning Reading Strategy*
- **Under ${sizeLimit}KB**: Get full data without depth parameter

## Figma Data Pruning Reading Strategy

**IMPORTANT: Work incrementally, not comprehensively.**

### Core Principle
Retrieve and implement ONE node at a time. Don't try to understand the entire design upfront.

### Pruning Reading Process
1. **Start Small**: Get shallow data (depth: 1) of the main node to see basic information of itself and children nodes
2. **Pick One**: Choose one from the child nodes to implement completely
3. **Get Full Data**: Retrieve complete data for that one node only
4. **Implement**: Implement specifically according to user needs based on the content of the node
5. **Repeat**: Move to the next node only after the current one is done

### Key Point
**Don't analyze multiple nodes in parallel.** Focus on implementing one complete, working node at a time. This avoids context overload and produces better results.

[GLips]

Sweet. I just released what we've got here to a new beta package and let folks in the Discord know. Gonna keep experimenting myself and see if we get any feedback in there. Hope we can cut a main release for this later next week.

[fightZy]

I have added an optional caching function to the data acquisition logic, which has a significant speed advantage when repeatedly reading data from a large file. Additionally, I updated the Figma API version to use a new interface. I noticed some new data types and have done simple adaptations, but haven't tested the adaptation for the new types yet, as I haven't found design files with corresponding data.
It may be necessary to further consider the handling of new data types. Looking forward to your reply. @GLips

[stone-w4tch3r]

Are there any plans to continue work on this PR and merge it?

I hope that caching feature will allow to use this MCP with figma free plan