Figma with DevFlow: setup, scope and limits

With a Figma personal access token stored for the workspace, DevFlow starts a design-context MCP server inside each OpenCode run. Planning and implementer agents can then read layout, design tokens and screenshots from the frame URLs a task description mentions. Setup is 5 steps in Workspace Settings → Integrations.

Kind

Design context

Where to set it up

Workspace Settings → Integrations

Plan

All plans

Agent roles

planning, implementer

Verified

1 Oct 2026

Setup steps

1. Create a personal access token. In your Figma account settings, create a token with the scope "File content → read-only" and copy it right away: it is shown only once.
2. Open the panel. As a workspace owner, open the Integrations tab of Workspace Settings. The Figma panel there is visible to owners only; the same key also appears under Billing → Model access, where the Figma card is always listed, unlike the hidden first-party model cards.
3. Save the key. Until a key exists the panel reads "Not set". Paste the value into the "API key" field and click "Save". The panel then shows "Set" with a masked copy, "Replace" swaps in a new value later and clears the previous test result, and "Remove" deletes it, after which the next run starts without the MCP server.
4. Test the key. Click "Test". DevFlow calls the /v1/me endpoint with the X-Figma-Token header, the cheapest authenticated request, and reports whether it was accepted; a value typed but not yet saved is tested first, and with nothing typed the stored key is checked.
5. Reference frames in tasks. Paste frame URLs into a task description. During planning and implementation, the agents open those frames through the MCP tools.

What it does

The credential is kept under the key name FIGMA_API_KEY, in the same encrypted table as model provider keys. Its presence is the switch: without it, no MCP server starts and runs pay no startup cost.

Each run's OpenCode configuration registers figma-developer-mcp version 0.13.2 over stdio and hands it the secret through an environment reference, so the value never lands in the configuration file. The agent file written for every role then turns the matching tools on or off.

In container mode the shared runtime volume ships Node 22.12.0 together with the same server. The secret reaches the container through its env file, as a non-model key, while model keys stay out of that file.

Code-writing roles go through an egress allowlist, which already admits every subdomain of figma.com and one Amazon S3 bucket host.

The server version is pinned in a single constant, and a test keeps the API image and the runtime volume on that same version, so every run gets identical tools.

The OpenCode configuration file lives in a directory DevFlow owns, outside the repository worktree.

Requirements

• The OpenCode agent backend, DevFlow's default; the optional Claude Code backend starts no such server.
• The owner role in the DevFlow workspace, because every key route is owner-only.
• A personal access token whose account can open every file and frame that your tasks reference by URL.

Limits

• Only the planning and implementer roles get the Figma tools; the verifier, the summarizer and every other role run with them switched off.
• One token per workspace, so every task reads designs as the same account; the key is read again for each run, so a replacement applies to runs that start afterwards.
• The one-shot run that repairs malformed JSON output gets no MCP tools, because that run is allowed no tools at all, not even built-in ones such as reading files.

Sources

Every fact above comes from these files in the DevFlow repository.

• internal/agent/opencode_backend.go
• internal/agent/opencode_bootstrap.go
• internal/agent/agentruntime.go
• internal/api/opencode_key_tester.go
• internal/api/handlers_opencode_keys.go
• internal/api/server.go
• internal/egress/policy.go
• web/src/lib/components/FigmaKeyCard.svelte
• web/src/lib/components/ApiKeysManager.svelte
• web/src/lib/components/WorkspaceSettings.svelte
• CLAUDE.md