Figma's own docs show a get_design_context response of 351,378 tokens against a 25,000 limit. This article explains what inflates Figma MCP output, how to measure each call, and seven fixes, from get_metadata to Code Connect, that keep responses small.
You paste a Figma link into your coding agent, ask for one pricing card, and the run dies with an error about response size. Figma's own troubleshooting page shows the exact message: a get_design_context response of 351,378 tokens against a 25,000 token ceiling. That request overshot the cap by a factor of fourteen. And even when a response squeaks under the limit, it still lands in your context window, shoves earlier instructions out of reach, and gets re-read on every turn that follows.
This article shows why the Figma MCP server produces so much output, how to see what each call costs, and seven changes that shrink the numbers without making the generated UI worse. The tool names and limits come from Figma's published docs. The workflow advice comes from what happens when big design files meet small context windows.
A node link does not return one rectangle. get_design_context extracts the design context of the selected layers and hands it back as code, React plus Tailwind by default, with other frameworks available. Select a full page frame and every nested layer comes with it: nav bars, cards, icon instances, text styles, auto layout rules, spacing.
A busy landing page can hold thousands of nodes, and each node carries a name, a size, fills, strokes, padding and type settings. Turned into code, all of that becomes long class lists and deep markup. Long class lists tokenize badly. A common rule of thumb is about four characters per token for English prose, and dense code and markup usually squeeze fewer characters into each token.
Four things tend to inflate a response fastest:
One design request often triggers several read tools, and each one adds its own payload. Figma's tool reference lists them:
| Tool | What it returns | Relative size | Best use |
|---|---|---|---|
get_metadata | Sparse XML outline with layer IDs, names, types, positions and sizes | Small | Mapping a large frame before fetching anything |
get_design_context | Layer styling and structure as code, React and Tailwind by default | Large, grows with the subtree | Building one component or one section |
get_screenshot | PNG of the selection to preserve layout fidelity | Medium, image tokens | Visual check of the result |
get_variable_defs | Variables and styles used in the selection: colors, spacing, typography | Small to medium | Matching design tokens |
download_assets | PNG, JPG, SVG or PDF exports, or the original source images | Depends on the assets | Saving icons and photos as files |
get_code_connect_map | Node ID to code component mappings | Small | Reusing components you already ship |
The size column describes what each tool returns in general. Real counts depend on your file, so measure before you trust any label.
Tool results stay in the conversation. Say a pull returns 40,000 tokens: every later message now carries that weight. Prompt caching can lower the price of re-reading it, but the tokens still occupy the window, so they crowd out your source files, test output and instructions. Long sessions then trigger automatic compaction, which summarizes away details you wanted to keep.
💡 Quick check: if the agent gets slower or forgets earlier instructions right after a Figma call, blame the oversized response before you blame the model.
Most clients show how full the window is. In Claude Code the /context command does it. Check the number before and after each Figma call. The difference is the real cost of that call, screenshot included, and it is the only number that matters for your file.
Pick one real frame and run three calls in a fresh session, writing down the context size after each:
get_metadata on the full frame.get_design_context on the full frame.get_design_context on one child node taken from the metadata.Log the results in a table like this one:
| Call | Node | Context added | Notes |
|---|---|---|---|
get_metadata | Full frame | Fill in | Outline only |
get_design_context | Full frame | Fill in | Check for the size error |
get_design_context | One child | Fill in | Compare with the row above |
After a few frames you will have your own cost curve, which beats any number in a blog post, this one included. My own rule of thumb: aim for pulls small enough that you can do five or six of them in one session before compaction kicks in. If one pull alone eats a third of the window, the node is too big.
Roughly in order of how much they tend to save.
Figma points to get_metadata for very large designs because it returns a sparse XML outline, with no styling attached. Read the outline, choose the section you actually need, then call get_design_context on that node ID only.
Run get_metadata on this frame. Do not call get_design_context yet.
List the top level sections with their node IDs and wait for my pick.
The server works from the node you select or link. Link the button, not the page. Build a page the way a person would: header, hero, pricing, footer, each as its own request.
Tidy the source file too. Unused layers and deeply nested groups can add nodes the output has to describe, so a ten minute cleanup by the designer often pays for itself on the very next pull.
Figma's docs say to set up Code Connect for the best code reuse results. Mappings link a Figma node to a real component in your repo, through get_code_connect_map and add_code_connect_map. Instead of rebuilding a button from raw styles on every request, the agent can point at the button you already ship. That means less generated code and fewer review comments.
One difference to watch: the desktop server uses the mappings you select, while the remote server needs the clientFrameworks parameter set to a specific label such as React or SwiftUI.
When designers apply variables and styles for color, spacing and type, get_variable_defs returns the ones used in the selection. Output that references a token name beats the same hex code and pixel value repeated across hundreds of elements, and it lines up with the tokens already in your stylesheet.
💡 Ask the design team to bind fills and spacing to variables before the first MCP pull. It costs them minutes and spares every later request.
React and Tailwind is the default output. If your project runs Vue, SwiftUI or plain CSS, a React answer needs a second pass to convert, and you pay for both. Name the stack in the prompt, and on the remote server set clientFrameworks explicitly. The same goes for styling: say whether you use Tailwind, CSS modules or a component library, because mixing approaches in one pass is how rewrites start.
Use download_assets to export icons and photos as files into the repo, then reference them by path. Do not make the agent re-read an image node for every component that shows the same logo. Exports can be SVG for icons and PNG or JPG for photos, so pick the format your build already uses. Once the files sit in the repo, later prompts only need the file path.
Figma notes that screenshots can be switched off if token limits are a worry, though it recommends leaving them on because they preserve layout fidelity. A fair middle path: keep them for the first build of a section, drop them for small edits like a label change or a padding tweak.
The error message suggests raising MAX_MCP_OUTPUT_TOKENS, and Figma's troubleshooting page names 50000 or 100000 as example values. In Claude Code you set the variable in the environment settings and restart the app. That unblocks the call, but it changes nothing about how many tokens the response contains. A bigger cap just lets a bigger pile into the window.
If the size error still shows up after you fetch a single section, the node itself is heavy. Split it: ask get_metadata for the children of that node, then pull them one at a time. If one component still returns too much, the cause is usually a very long instance list or a text-heavy layer, and the fix belongs in the Figma file, not in the prompt.
| Approach | Effect on context | When it makes sense |
|---|---|---|
Raise MAX_MCP_OUTPUT_TOKENS | None, it only lets larger responses through | A rare one-off pull you cannot split |
| Fetch child nodes | Cuts response size sharply | Default for anything bigger than a section |
| Turn off screenshots | Removes the image payload | Small edits |
| Code Connect | Shrinks the code the agent writes | Any project with a component library |
| Fresh conversation per section | Clears old payloads | Long sessions |
The rules file can stay short. Something like this is enough:
Design to code rules
- Framework: React with Tailwind. Reuse components from src/components first.
- Colors and spacing: use the tokens in src/styles/tokens.css, never raw hex values.
- Figma: call get_metadata first on any frame larger than one section.
- Fetch one node per request. Do not re-pull a node that is already built.
It costs a few dozen tokens per session and blocks the most expensive habits before they start.
get_metadata and pick one node.Take a pricing page with a header, three plan cards, an FAQ and a footer. The expensive route is one link to the whole frame and the prompt "build this page". The lean route looks like this:
get_metadata on the page frame returns the outline and the node IDs.get_design_context for one plan card, with screenshots on.PlanCard component with props for name, price and features.Three plan cards, one design pull. Over a whole page, that gap between "one pull per section" and "one pull for everything" is where most of the savings come from.
| Mistake | Why it costs | Fix |
|---|---|---|
| Linking the full page | The whole subtree comes back | Link one section |
Calling get_design_context twice on one node | The same payload lands in context twice | Reuse the first result |
| Re-pulling for a small tweak | A new payload for a one-line change | Edit the code directly |
| Raising the cap by default | Oversized pulls become normal | Keep the default, raise it temporarily |
| Ignoring the framework | A second conversion pass | Name the stack first |
Some fixes belong in the Figma file, not in the prompt. Ask the design team to split long flows into one section per frame, name sections after what they are, and keep reusable components in a library instead of copying them across pages. A tidy file gives get_metadata a clean outline to work from, which makes every later pull smaller and easier for the agent to read. Share your same-frame numbers with them too. Seeing a pull drop from enormous to modest is the quickest way to turn token costs into a design habit.
Several community servers claim to compress Figma data into leaner output. They can be worth a look, but run the same-frame test against them before you switch, and check what they leave out. A smaller response is only a win if the layout details you need survive.
A design to code run involves more than Figma calls. Plenty of the surrounding work does not need to happen inside your coding agent's context at all, and that is where the models in the PicassoIA Large Language Models collection help.
Images are another place to save. Hero photos and placeholder shots do not have to travel through the Figma server. Generate them from a prompt with Flux 2 Pro, Seedream 4.5 or P-Image, and none of it touches your coding agent's context. Need motion for a landing page? Seedance 2.0 and PicassoIA Video turn a prompt or a still into a short clip.
Your next design to code session will go faster when the images are ready before the first prompt. Open Picasso IA, write a short scene description, and run it through Flux 2 Pro and Seedream 4.5 side by side. Keep the one that fits your layout, then animate it with Seedance 2.0 if the page needs a moving hero.
Try a handful of prompts today and see which look you prefer. Every model is listed at picassoia.com/en/all-models, so you can test as many as you like.
