# Figma MCP access for Cursor: a governed rollout

> Set up Figma MCP access for Cursor: the restrictions that stop the obvious write, and the audit query that proves they held.

**TL;DR** Elaichi carries Figma into Cursor through one MCP address, either as a catalog connector or as a remote MCP server your organization adds itself. Hold engineers to reads with block or allow rules on their role, decide whose Figma account each call runs as, and freeze the file argument on a shared toolbox entry. Prove it afterwards in the audit log's assistant category, filtered to that connector.

A design system lives in Figma. The engineers building against it work in Cursor. They keep asking a designer for a hex value, a spacing token, or the exact name of a component variant. So the request that reaches IT is Figma MCP access for Cursor, for the design and engineering teams, with reads for everyone and writes for nobody. The second half is where most rollouts go wrong.

## Can you set up Figma MCP access for Cursor today?

Check the connector catalog first, because that answer decides everything after it. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves MCP at one address, https://api.elaichi.ai/mcp, and that address is the same for every organization.

Elaichi's catalog holds two kinds of connector. Most are connectors Elaichi authors and runs itself. The rest are native MCP connectors, where the vendor builds and runs the MCP server and Elaichi handles sign-in, access and audit in front of it. Those carry a Native MCP badge and a vendor support contact.

Start at [Figma's connector page](/connectors/figma/), and read it against the wider [connector catalog](/connectors/), because the catalog changes with each connector sync. If an app you need is not listed, an organization on Gold can add a remote MCP server as its own connector. That needs the connector:create permission, which among the system roles only Org Owner and Org Admin hold. The server has to speak MCP over Streamable HTTP and be reachable over public HTTPS. No localhost, no IP literals, no internal hostnames.

What Figma's own MCP server offers, if it publishes one, is a question for Figma's documentation. Nothing here states it. The same fork in the road, for a vendor server an engineering team already uses, is walked through in [bringing GitHub's MCP server under one sign-in](/blog/github-mcp-server-for-a-company-with-sso/).

One more thing about the word official. If an engineer points Cursor straight at a vendor's own MCP server, those calls never pass through Elaichi, so none of the rules below touch them. Cursor reads MCP servers from .cursor/mcp.json in a project and ~/.cursor/mcp.json in the home directory, and a remote entry is defined with a url field ([cursor.com/docs/mcp](https://cursor.com/docs/mcp), checked October 2026). Decide which path you are on before writing a single rule.

## Why Cursor's approval prompt will not separate Figma from Jira

Cursor asks for approval before using MCP tools by default, and MCP calls follow the same Run Modes as terminal commands ([cursor.com/docs/mcp](https://cursor.com/docs/mcp), checked October 2026). That prompt is useful. It is not a per-app control over Elaichi.

What Cursor sees from Elaichi is a short list: search_tools, execute_tool, run_code where Code Mode is available, and Elaichi's own elaichi__ operations. In Elaichi, connected tools are never listed one by one, however few there are. The model finds one with search_tools and runs it with execute_tool. A client control that picks individual MCP tools therefore acts on execute_tool as a whole, and cannot tell a Figma call from a Jira call.

The consent screen does not solve it either. "Run your connected tools" covers every tier of connected tool, writes and deletes included. "Delete data and remove access" governs Elaichi's own data, not a connected app's. No checkbox makes a connected app read-only. Per-app and per-tool separation lives in Elaichi, and the choice between those two levels is its own decision: [restrict one AI tool or the whole app](/blog/per-tool-vs-per-app-restrictions/).

## Restriction one: block the Figma tools that change a file

A restriction is a rule saying which connectors and tools a role, or one named member, may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. So "the engineering team" becomes a role, or a rule written per member. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule.

Blocks and allows do not behave the same way. A block rule matches a tool by name or by the operation it performs, so renaming a tool does not slip it past a block. An allow rule matches only the operation pinned when the rule was saved. That asymmetry has caught people out, and it is worth reading once: [why blocks match tool names but allows don't](/blog/block-matches-name-allow-matches-operation/).

The trap in a read-only rollout is quieter. A layer with only block rules has no allowlist, so everything the blocks do not name stays reachable. Block three Figma write tools and the fourth still runs. Two honest ways out:

- Name every non-read tool on that connector in the block rule.
- Write an allow rule naming the read tools you want, plus an allow rule for each other app that role uses.

The second option needs its second half. One allow rule turns on the allowlist for the whole layer, so every connector the role's allow rules do not name is blocked. An allow rule that names nothing blocks everything for its target.

A restriction change takes effect within about two minutes.

## Restriction two: decide whose Figma account each call runs as

Every call through a connection uses that connection's own account, whoever is calling. A connection shared at use reaches Figma as its owner, not as the engineer typing in Cursor. A connection each person makes with their own sign-in carries that person's own Figma permissions.

Pick one on purpose. Per-person connections keep Figma's own access model doing the work. A single shared connection gives everyone one fixed set of permissions, which is simpler to reason about and wrong for anyone who should see less.

Absent any restriction, a Member can connect any catalog connector with their own account, because connection:create is a default Member permission. If only engineering should reach Figma through Elaichi, a block on the other roles does the work at connect time as well. Restrictions are checked when connectors are listed, when an account is connected, when tools are advertised to a client, and when a call runs.

Designers do not need Cursor for any of this. The same grant works from Claude or ChatGPT at the same address, because the grant decides the organization and the person, not the URL. Claude's custom connectors that use remote MCP work in Claude, Cowork and Claude Desktop ([support.claude.com](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp), checked October 2026).

## Restriction three: pin the file or project with a locked-in value

Frozen parameters, labeled "Locked-in values" in the console, write an argument into a toolbox entry that a caller cannot override. If a Figma tool takes a file or project argument, freezing it keeps the agent inside the design system instead of last quarter's exploration files.

Two things to be straight about. The AI client can see that a value is frozen, and often the value itself, because the tool's description carries a note; it cannot change it. And a freeze holds only on calls that run through that entry. Anyone who can use the connection has the same tool unfrozen in their All tools toolbox.

So the pattern that holds is this: the connection's owner keeps the connection unshared, pins it into a toolbox entry with the frozen value, and shares the toolbox at use. Do not try to close the unfrozen path with a restriction, because a restriction blocks the tool inside the frozen entry too. It matches the catalog tool, evaluated for the person calling. The mechanics are set out in [locking an agent's tool arguments](/blog/frozen-parameters-wire-transfer-receiver/).

## The audit query that proves the restrictions held

Filter the audit log to the assistant category, not the MCP category. Connected-tool calls are recorded as assistant.toolbox_tool, and the category follows the action name. The MCP category holds grant actions, such as a client being connected or disconnected.

Each connected-tool row records the person, the toolbox, the tool's advertised and catalog names, the connector, the connection the call actually reached, what it touched, whether approval was needed and how it was given, the surface, the MCP client, and the outcome. In the console the detail panel writes a sentence that opens "Using Cursor,", with a "What it did" line reading Read data, Changed data or Deleted data.

The query is two-sided:

- Presence: rows for the engineering role's members, on the Figma connector, with What it did reading Read data.
- Absence: no row on that connector whose What it did reads Changed data or Deleted data.

The absence half carries one caveat, and it is the first thing a reviewer asks. A call a restriction refuses before execution writes no audit row at all. The log proves what ran; it does not list what was stopped. Evidence that the rule existed is separate: restriction writes are recorded as restriction.created, restriction.updated and restriction.deleted.

Filters are free text, category, actor, action kind and a start time, with no end-time filter. The console offers All time, Last 24 hours, Last 7 days and Last 30 days, and All time covers at most the last 400 days. Every member reads their own events; reading the whole organization needs audit:view, which Org Owner, Org Admin and Auditor hold, and Auditor does not take a billable seat. Elaichi keeps 90 days of audit history. For longer, forward it to your own log service: that comes with the Black plan, which is launching soon, and Datadog is the destination that delivers.

An MCP client can read the log as well, but that operation takes only a page size and a cursor. Run the real query in the console. [What an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/) covers the fields worth arguing about.

## When you do not need any of this

If design and engineering are six people on one Figma team, everyone already holds the same Figma access, and nobody has asked you for an access review, stop here. Each person connecting their own Figma account and answering Cursor's approval prompt is a reasonable place to be. The case for an endpoint in front arrives when the app count grows, when access stops being uniform, or when someone needs evidence after the fact. That threshold deserves an honest look: [when you don't need an MCP gateway yet](/blog/when-you-dont-need-an-mcp-gateway/).

## Rollout order that strands nobody

Six steps, in the order that avoids rework.

1. Confirm the connector in the catalog, or decide who will add a remote MCP server as the organization's own connector.
2. Choose the account model: per-person Figma connections, or one shared connection whose owner's access everyone inherits.
3. Write the role rules, either blocking every non-read tool or allowing the read tools plus every other app that role uses.
4. Build the toolbox, freeze any argument that should not move, and share the toolbox at use rather than the connection.
5. Have each engineer connect Cursor once and approve their own grant. A Team admin can distribute a shared MCP server, and the Enterprise MCP Allowlist approves a configuration rather than pushing it to machines ([cursor.com/docs/mcp](https://cursor.com/docs/mcp) and [cursor.com/docs/enterprise/model-and-integration-management](https://cursor.com/docs/enterprise/model-and-integration-management), checked October 2026).
6. Run the audit query a week later and read the What it did column.

For the Cursor side in detail, one shared address beats a per-developer config file: see [connecting Elaichi to Cursor](/blog/cursor-mcp-one-endpoint-vs-per-developer/). The same shape with a tracker instead of a design tool is in [rolling Cursor out to an engineering team](/blog/engineering-team-cursor-jira/). The rules themselves sit under [MCP governance](/blog/mcp-governance/), and the apps you can put behind them are in the [connector catalog](/connectors/).

## FAQ

### Is there a Figma connector in Elaichi's catalog?

Check the catalog at elaichi.ai/connectors, because it changes with each connector sync. If an app is not listed, an organization on Gold can add a remote MCP server as its own connector. That needs the connector:create permission, which among Elaichi's system roles only Org Owner and Org Admin hold, and the server must speak MCP over Streamable HTTP and be reachable over public HTTPS. What Figma's own MCP server offers is a question for Figma's documentation.

### Can I make Figma read-only for engineers inside Cursor?

Not with a consent checkbox. In Elaichi, the "Run your connected tools" permission covers every tier of connected tool, writes and deletes included, and "Delete data and remove access" governs Elaichi's own data rather than a connected app's. Hold a role to reads with restrictions: either block every non-read tool on that connector, or write an allow rule naming the read tools plus an allow rule for each other app the role uses. A restriction change takes effect within about two minutes.

### Where do Figma tool calls from Cursor appear in Elaichi's audit log?

In the assistant category, recorded as assistant.toolbox_tool with the surface mcp and the MCP client's name. The MCP category holds grant actions such as a client being connected or disconnected, not tool calls. Each row records the person, the tool's advertised and catalog names, the connector, the connection the call reached, what it touched, how approval was given, and the outcome.

### Does a shared connection run as the engineer or as its owner?

As its owner. In Elaichi, every call through a connection uses that connection's own account, whoever is calling, so a connection shared at use reaches the third-party app as the person who connected it. For each person's own permissions to apply in the app, each person connects their own account, and the tools then run on their own connections.

### Do designers need Cursor to use the same setup?

No. Elaichi serves one MCP address for every organization, so the same connections and toolboxes reach Claude or ChatGPT as well. Each person connects their client once and approves their own grant, and the grant, not the URL, decides which organization and person the client acts as.

## Read next

- [Outreach MCP access for sales team in Cursor](/blog/sales-team-cursor-outreach-sequences/) — Outreach MCP access for sales team work in Cursor: allow sequence reads, block bulk enrollment and mailbox sends, and freeze the sequence owner.
- [GitHub MCP server for a company with SSO](/blog/github-mcp-server-for-a-company-with-sso/) — A GitHub MCP server for a company with SSO has two sign-ins to settle: your identity provider, and whose GitHub account the tool call actually runs as.
- [Linear MCP server for our engineering team](/blog/linear-mcp-server-for-our-engineering-team/) — A Linear MCP server for our engineering team changes whose account each call runs as, which tools stay on, and what the audit log keeps.