OpenCode Figma MCP Setup: 7 Checks Before You Connect Design Files

Figma MCP is useful when OpenCode needs structured design information during a coding task: component names, selected frames, spacing, tokens, copy, or design-system intent. It is less useful when a human can describe the mockup, when the design is not final, or when the repository already has a reliable component spec.

Do not install it just because MCP sounds powerful. Every enabled MCP server adds tool descriptions to context and introduces an auth surface. If the task is only to compare screenshots or write a short design note, a link to Figma and a manual summary may be safer. If the task repeatedly turns Figma frames into code, the integration becomes easier to justify.

Treat any command copied from a blog, package list, or social post as unverified until it matches the official server owner's documentation. Figma's Dev Mode MCP instructions and OpenCode's MCP configuration docs are the two sources that matter for the first setup. Provider-specific endpoints, OAuth behavior, and Dev Mode requirements can change independently from OpenCode.

Use this order: confirm the Figma MCP path, confirm the OpenCode MCP config shape, decide whether the entry belongs in global config or repository opencode.json, then document the authentication method. This keeps the integration auditable and prevents a temporary experiment from becoming invisible infrastructure.

Global config is convenient, but it makes Figma tools available in every OpenCode session. That is rarely the best default for a design integration. A project-scoped entry is better when one repository maps to one product or design system. Agent scope is best when only a design-implementation agent should see Figma tools.

The safer default is project or agent scope. Give the server a descriptive name such as figma_design, keep optional entries disabled until needed, and record which Figma files or teams the integration is meant to support. Avoid broad team-level access if the coding task only needs one file or component.

Use OAuth when the Figma MCP path supports it, or environment-variable references when the server owner documents token-based auth. Do not paste a live token into opencode.json. The config should reveal the required header, server name, and intended scope without exposing the credential itself.

If a token is necessary, start with the smallest Figma scope that can read the required design context. Rotate it if it appears in logs, shell history, screenshots, or support tickets. For team workflows, prefer a documented credential owner and a revocation path over a personal token that nobody else understands.

The first validation should be read-only. Run opencode mcp list, complete auth deliberately, inspect tool availability, then ask OpenCode to summarize one known frame or selected component. Compare the answer with Figma before asking for code edits. A wrong frame, stale selection, or missing permission is easier to catch before files change.

A useful verification note includes the server name, auth method, Figma file or team used for the test, a read-only prompt, the expected tool prefix, and a rollback command. Keep that note near the project setup documentation so future design-to-code failures start from evidence rather than memory.

1. ScopeDecide where the Figma MCP entry belongs.
2. AuthComplete OAuth or provide a token through environment variables.
3. ListRun opencode mcp list and inspect available tools.
4. Read-onlySummarize one known design object before editing code.

A strong prompt should name the design object, the target component or route, the allowed files, and the output expectation. For example: ask OpenCode to inspect the Figma frame, compare it with the existing button component, and propose a minimal diff before editing. That is safer than asking it to 'build this Figma page' with no repository boundary.

Keep generated code reviewable. Ask for a short implementation plan, then a small edit, then run the project's formatter or tests. If the design contains ambiguous spacing, typography, or component states, require OpenCode to state the assumption instead of inventing a hidden rule. Design context improves implementation only when the coding boundary remains explicit.

Separate five layers: Figma access, MCP server availability, OpenCode configuration, model tool visibility, and repository permissions. A 401 belongs to auth. Missing tools usually belong to config or discovery. A vague design answer can be a wrong file, a stale selection, or too many tools in context. A failed code edit may have nothing to do with Figma at all.

Change one layer at a time. Confirm the Figma source, then confirm MCP list/debug output, then run the read-only prompt, then edit a single low-risk component. If the agent starts ignoring design constraints, disable unrelated MCP servers and compare the same prompt with a smaller context.

OpenCode MCP, OpenCode Ollama, OpenCode session storage. Use this dedicated setup guide when the general MCP page is not specific enough for Figma design context.