Configure Figma MCP for OpenCode in one step

The problem with MCP configuration

Adding the Figma MCP to a single repository takes five steps. Keeping it updated across five repositories takes twenty-five — and when authentication breaks, everything stops. With ivar, that maintenance drops to zero steps.

You configured the Figma MCP in your harness, and your agent started reading designs. Great. Now do it across every other repository your product touches, and keep credentials in sync across tools and environments.

Here is what the manual process looks like in practice:

1. Register an OAuth client or find supported harness credentials for Figma.
2. Find the right config schema for your harness.
3. Add the MCP server definition to your project's configuration file.
4. Repeat for every repository the agent works in.
5. Authenticate separately across different harnesses and worktrees.

If you manage three repositories that share a design system, you are maintaining three separate copies of the same MCP configuration. Change the configuration in one and the other two are stale. Forget one and half your sessions have no Figma access.

How ivar changes this

Ivar's Hall carries a single source of truth for every MCP server your workflow needs. When you run ivar sync, the harness materialises the configuration into each session's view directory — the same directory where your agent reads its instructions, finds its repos, and runs its tools.

The Figma MCP server is defined once in ivar.json:

{
  "$schema": "https://ivar.run/schema/4.json",
  "name": "acme",
  "providers": {
    "available": ["opencode"],
    "default": "opencode"
  },
  "mcp": [
    {
      "name": "figma",
      "type": "http",
      "url": "https://mcp.figma.com/mcp"
    }
  ],
  "repos": [],
  "integration": {
    "via": "local",
    "strategy": "squash"
  },
  "version": 4
}

ivar mcp auth figma --provider opencode handles the entire authentication flow. Because Figma rejects OpenCode's dynamic client registration (DCR) identity, Ivar uses its internal OAuth flow rather than delegating the browser step to opencode mcp auth. Ivar performs prerequisite client preregistration when needed, runs an authorization-code flow with PKCE, persists non-secret metadata in ivar.json while keeping secret tokens local, and installs/verifies the provider credentials directly in OpenCode's MCP auth store.

After authenticating, ivar.json can record generated OAuth metadata:

{
  "mcp": [
    {
      "name": "figma",
      "type": "http",
      "url": "https://mcp.figma.com/mcp",
      "oauth": {
        "client_id": "<generated-client-id>",
        "client_secret_env": "IVAR_MCP_ACME_FIGMA_SECRET",
        "token_url": "<token-url>",
        "resource": "<resource>"
      }
    }
  ]
}

(Note: OAuth metadata shown above is generated; secrets and tokens are never committed to the manifest.)

Because Figma's external allowlist policy and DCR requirements can change at any time, Ivar isolates these quirks so your agent sessions remain uninterrupted.

For full details on Claude Code, OMP, Linear, configuration mappings, and authenticating with --all-providers, consult the MCP reference guide.

One Hall, every session

The moment you add the Figma MCP server to your Hall, every new session across every repository inherits it. There is no per-repo step. There is no configuration file to edit when you start working on a new codebase.

This is the same mechanism that makes multiple repositories accessible in a single agent session. The Hall is the unit of configuration; the session is the unit of execution. A change to the Hall propagates to every session that reads from it.

If you work with a design team that delivers in Figma, every agent session your developers run will have access to those designs — not because someone remembered to configure it, but because the Hall carries it.

What this does not do

Ivar does not modify Figma files, read design tokens from Figma variables, or sync design changes into code automatically. The MCP server gives your agent read access to Figma data — files, frames, comments, component metadata. What the agent does with that data depends on the prompt and the model.

Ivar's contribution is making sure the configuration reaches every session without manual duplication and that harness-specific auth barriers are resolved.

Setting it up

If you already have an Ivar Hall, adding the Figma MCP server is a one-block addition to ivar.json. Run ivar sync, authenticate with ivar mcp auth figma --provider opencode (or ivar mcp auth --all-providers), and the next session materialises with Figma access.

If you do not have a Hall yet, the quickstart guide walks through creating one. The MCP server configuration goes in the same place as your repos and instruction files — the Hall is the single place where everything your agent needs lives.

Related

• The context problem nobody solved: AI agents across multiple repos — why a single session across repos is the mechanism, not a convenience.