OpenCode is an open-source terminal AI coding agent that supports the Model Context Protocol. It runs in your terminal, reads and edits project files, and can be extended with MCP servers including Figma MCP. Compared to Claude Code, OpenCode is model-agnostic — you can pair it with Claude, GPT-4o, Gemini, or a local model — and its configuration is TOML-based, which many developers find more readable than JSON for multi-server setups.
This topic covers installing and configuring Figma MCP for OpenCode, extracting design context, translating a Figma frame to a React component end-to-end, and understanding the limitations you'll encounter in practice.
Installing and Connecting Figma MCP to OpenCode
Prerequisites
- OpenCode installed — check the latest install method from the official repo, typically:
curl -fsSL https://opencode.ai/install | bash
npm install -g opencode-ai
- A Figma account (free or paid)
OpenCode MCP configuration
OpenCode reads its configuration from ~/.config/opencode/config.toml. Add Figma MCP using HTTP transport to connect to the official Figma MCP server:
[mcp.figma]
type = "http"
url = "https://mcp.figma.com/mcp"
That's all that is required — no API key, no npx command, no local server process.
Authentication
Start OpenCode and authenticate by running a Figma tool:
Use the Figma MCP tool to list the pages in file ABC123
OpenCode will open your browser for Figma OAuth. Complete the login and grant access — OpenCode stores the resulting auth token and reuses it in subsequent sessions.
Project-level config
OpenCode also supports a project-level .opencode/config.toml in your project root. This is the right place for team-shared configurations:
[mcp.figma]
type = "http"
url = "https://mcp.figma.com/mcp"
Commit this file to version control — it contains no secrets.
Verify the connection
Start OpenCode and run a quick test:
Use the Figma MCP tool to list the pages in file ABC123
Tips
- The project-level config takes precedence over the global config. Use global for personal setup, project-level for team setups.
- If OpenCode reports the Figma tools as unavailable, restart OpenCode after editingconfig.toml— changes are not hot-reloaded.
Extracting Design Context and Generating Code from Figma Frames in OpenCode
OpenCode's agent loop follows the same MCP tool-calling pattern as other agents — it calls Figma MCP tools, processes the response, and uses the results to inform code generation. The key difference is how you structure prompts given your chosen model's context window and instruction-following style.
Getting the node ID from Figma
Right-click the target frame in Figma, choose "Copy link to selection". The URL looks like:
https://www.figma.com/design/ABC123/DesignSystem?node-id=88%3A204&t=xyz
The node ID is 88:204.
Design context extraction prompt
Use the Figma MCP get_design_context tool for node-id=88:204 in file ABC123. Summarize:
- Layout mode and direction (is this a flex container? horizontal or vertical?)
- All child layer names and their types (frame, text, instance, etc.)
- Spacing values: padding, gap, margin equivalents
- Color fills: list unique hex values
- Typography: all text nodes with their font, size, weight, and content
- Component instances: list Figma component names
Do not write code yet.
Screenshot-assisted extraction (for vision models)
Use Figma MCP to:
1. Call get_design_context for node-id=88:204 in file ABC123
2. Call get_screenshot for the same node
Then describe the layout as you see it visually from the screenshot, and note any discrepancies between what the screenshot shows and what the design context JSON describes.
This cross-reference step catches cases where the design context misses visual details like overlapping layers, drop shadows, or gradient fills that are complex to represent in structured data.
Tips
- In OpenCode, name your prompts clearly in the session log — many configurations support session titles or notes, which helps when returning to a complex design task the next day.
- If the design context JSON is very large (deeply nested frames), ask OpenCode to summarize it in bullet points before generating code. This focuses the model on the relevant structure rather than getting lost in noise.
- For multi-frame flows (e.g., a modal with open/loading/error states), extract all frames in a single prompt and ask the agent to identify shared vs. state-specific elements before any code is written.
- Useget_screenshotas a visual spec that travels with the session — reference it in later turns with "as shown in the screenshot you retrieved earlier" to keep the agent grounded.
Practical Example: Translating a Figma Frame to a React Component in OpenCode
This section walks through a complete end-to-end example: translating a "UserProfileCard" Figma frame to a production-ready React component.
Starting context
- Figma file ID: XYZ789
- Frame node ID: 120:55 (a UserProfileCard component showing avatar, name, role, and a follow button)
- Project uses React 18, TypeScript, CSS Modules, and has an existing <Button> component
Turn 1: Orientation
Use Figma MCP to get the design context and screenshot for node-id=120:55 in file XYZ789.
Identify:
1. The overall layout (flex row or column?)
2. The avatar element — is it a Figma component instance? What size?
3. The text content — how many text elements and what are their apparent hierarchy roles (heading, subheading, etc.)?
4. Is the "Follow" button a component instance? What Figma component name?
5. Any spacing or padding values.
Turn 2: Token mapping
The design context includes these fill colors:
- #1A1A2E (dark navy — used on name text)
- #6B7280 (gray — used on role text)
- #3B82F6 (blue — used on follow button background)
Check src/styles/tokens.css and map each of these to the closest existing token. If there's no exact match, suggest a token name following our existing naming convention.
Turn 3: Component generation
Generate the UserProfileCard component based on the design context from node-id=120:55 in file XYZ789.
Requirements:
- File: src/components/UserProfileCard/UserProfileCard.tsx
- CSS Module: src/components/UserProfileCard/UserProfileCard.module.css
- Props: userId (string), name (string), role (string), avatarUrl (string), isFollowing (boolean), onFollowToggle (() => void)
- Use the existing <Button> component from src/components/Button/ for the follow button
- Avatar should use an <img> with proper alt text derived from the name prop
- Apply tokens from src/styles/tokens.css using CSS custom properties
- The card should be keyboard navigable and have role="article"
- Export as a named export
Turn 4: Review and refinement
Looking at the generated UserProfileCard:
1. The avatar container in Figma has a border-radius of 50% (circular) — the generated CSS uses border-radius: 8px. Fix this.
2. The Follow button in Figma shows a filled state when isFollowing=true (white text on blue) and an outlined state when false (blue text, blue border, transparent background). Add these two visual states to the CSS module.
3. Run tsc --noEmit on the generated file and fix any type errors.
Turn 5: Storybook story
Generate a Storybook 7 CSF3 story file for UserProfileCard at src/components/UserProfileCard/UserProfileCard.stories.tsx.
Include:
- Default: not following
- Following: isFollowing=true
- LongName: a name that is 40+ characters to test text truncation
- Controls for all string props
Use a decorator to set a max-width of 360px on the story container to match the design frame width.
Tips
- Structure your OpenCode sessions as numbered turns in a logical sequence (orient, map tokens, generate, refine, stories) — it keeps the context focused and makes it easier to backtrack if one step produces bad output.
- After each generation step, read the file back and verify it before the next turn. Use OpenCode's file read capability: "Read src/components/UserProfileCard/UserProfileCard.tsx and confirm it matches the following requirements: ..."
- Save frequently referenced Figma node IDs in a.opencode/figma-nodes.tomlor aDESIGN.mdin the project root — team members can reuse them without hunting through Figma.
- Keep Storybook and test generation as separate turns rather than bundling everything into one prompt — the model stays more focused and produces higher-quality output for each artifact.
Known Limitations and Workarounds for Figma MCP in OpenCode
Understanding where Figma MCP falls short helps you plan your workflow and set realistic expectations.
Limitation 1: Complex gradients and visual effects
Figma MCP's design context represents gradients as structured data (type, stops, angle), but CSS gradient syntax is verbose and the model may produce slightly incorrect gradient strings for multi-stop or radial gradients.
Workaround: Ask the agent to generate the gradient CSS, then visually compare against the screenshot. Provide the screenshot and ask it to correct the gradient until it matches.
The gradient on the card header background in the screenshot doesn't match the generated CSS. The Figma design context shows a linear gradient at 135 degrees from #667EEA to #764BA2. The current CSS reads: background: linear-gradient(135deg, #667EEA, #764BA2). Visually compare the screenshot and adjust if needed.
Limitation 2: No prototype or interaction data
Figma MCP does not expose prototype connections, transitions, or interaction triggers. You cannot ask "what happens when the user clicks this button in the prototype" — MCP only covers visual structure.
Workaround: Supplement with written interaction specs in your prompt, or use Figma's developer mode annotations to document behavior directly on components.
Limitation 3: Model context window and large frames
Very large, deeply nested frames can produce design context JSON that approaches or exceeds the model's context window, especially on smaller context models.
Workaround: Focus on specific sub-frames (child node IDs) rather than parent frames. Break complex pages into sections and generate components section by section.
From the design context of node-id=200:10 in file XYZ789, give me only the node IDs of the direct children of this frame. I want to process each section separately.
Limitation 4: Model-specific tool-calling differences
When using OpenCode with non-Claude models, tool-calling reliability varies. GPT-4o handles MCP tool calls well; smaller open-weight models may struggle to chain multiple Figma tool calls in a single turn.
Workaround: With less capable models, call tools one at a time (one prompt per tool invocation) rather than asking the agent to chain multiple Figma MCP calls in a single turn.
Limitation 5: Figma file access latency
For very large Figma files with hundreds of components, get_design_context can take several seconds to respond. OpenCode's default timeout may need adjustment.
Workaround: Increase the MCP server timeout in OpenCode config:
[mcp.figma]
type = "http"
url = "https://mcp.figma.com/mcp"
timeout = 30000
Tips
- When a design context response is too large, ask the agent to summarize it to a flat list of layers with just name, type, and depth before doing anything else — this prunes the context and keeps the model focused.
- Test your setup with a small, known Figma frame (e.g., a simple button component) before tackling complex layouts — this isolates configuration issues from workflow issues.
- If the agent silently skips a Figma tool call (claims it extracted context without actually calling the tool), add explicit instruction: "You MUST call the get_design_context MCP tool. Do not infer or guess the design context."
- For teams using OpenCode with varying model choices, standardize on Claude or GPT-4o for Figma MCP sessions — vision capability and reliable tool-calling are both required for consistent results.