Figma's MCP Allowlist Is Spec-Compliant, and That's the Real Problem

The Model Context Protocol tells an agent how to knock. It never promised the door would open.

Point an unlisted MCP client at Figma's remote server and it fails before it ever sees a tool. The server at mcp.figma.com/mcp answers the client's registration request with an HTTP 403, and that is the end of the conversation. On October 1 a post about Figma "excluding Pi" from MCP access climbed the Hacker News front page, and the replies split along a familiar line: MCP is supposed to be open, so this must be a violation.

It isn't. Read the protocol's own authorization spec and Figma is doing something the spec explicitly allows. That is the more uncomfortable finding, and it changes what builders should be asking for.

What Figma actually does

Figma's developer docs state the policy in one line: "Only clients listed in the Figma MCP Catalog like VS Code, Cursor, or Claude Code can connect to the Figma MCP Server." Developers who want a new client added can join a waitlist. Figma docs

This is not new. A thread on Figma's community forum, opened on April 1 by a user whose OpenCode client hit the same 403, drew a reply on May 1 from Jaycee Lewis, a Figma staff member, explaining that the mcp:connect scope is "intentionally gated to supported clients while we're in beta." The reply offered a workaround: the Figma desktop app runs its own local MCP server that skips OAuth entirely. Figma forum

The Pi coding agent ran into the wall too. On September 30 the maintainers of pi-mcp-adapter merged a change that makes the workaround discoverable: it adds "Figma (desktop)" as a setup option when the app is detected and points users at http://127.0.0.1:3845/mcp when the remote registration is refused. The PR's summary is blunt: Figma's remote server "only accepts OAuth clients on its allowlist." pi-mcp-adapter #750

So the facts are simple. A remote MCP server refuses clients it hasn't approved, a local server doesn't ask, and the community is routing around the first through the second.

Why the spec is on Figma's side

The MCP authorization spec (version 2025-11-25) describes three ways a client can identify itself to an authorization server. MCP spec

Pre-registration. The client and server already have a relationship, and the client uses a client ID it was issued ahead of time.
Client ID Metadata Documents. The client uses an HTTPS URL as its client ID, and the server fetches a JSON document at that URL to learn the client's name and redirect URIs. The spec says servers and clients SHOULD support this.
Open registration under RFC 7591 (DCR). The client posts to a registration endpoint and gets a client ID with no human in the loop. The spec says servers and clients MAY support it, and adds that it is "included for backwards compatibility with earlier versions of the MCP authorization spec."

Read the levels again. The mechanism that would let any client walk up and register is optional. And in the security section on metadata documents, the spec lists acceptable "trust policies" for authorization servers, starting with "Allowlists for trusted domains (for protected servers)," followed by a line that settles the argument: "Servers maintain full control over their access policies."

Figma's allowlist is a trust policy. The spec names it as one.

I think this is the part the outrage misses. MCP standardizes the handshake: how a client discovers the authorization server, how it requests scopes, how tokens are bound to a specific server with the resource parameter. It does not standardize admission. A server can implement every MUST in the document and still say no to you.

The stakes: a protocol with private guest lists

The HN reaction makes sense once you see what MCP was sold as. The promise was that any agent could talk to any tool through one protocol, the way any browser can load any website. The spec delivers the second half of that sentence. The first half depends on each server's business decisions.

For a design tool, those decisions have real reasons behind them. A remote MCP server that can read and write a team's design files is a juicy target, and an approved-client list is the bluntest way to keep a hastily built client from becoming the weak link. Figma's "while we're in beta" framing suggests it sees the list as temporary.

But the cost lands on the long tail. The clients named in Figma's docs are the big IDEs and the big labs' coding tools. Every smaller agent, every internal harness a company builds for itself, every new open-source client, starts on the waitlist. If the most useful remote MCP servers adopt the same posture, the client market consolidates around whoever already has partnership deals, and "open protocol" ends up meaning something closer to "open spec, partner program."

There's a second, quieter cost. The workaround everyone is reaching for moves the trust boundary somewhere worse.

The localhost fallback is not a free lunch

The Figma desktop server at 127.0.0.1:3845 needs no OAuth. That's why it works for Pi and OpenCode. It also means any local process that can reach that port can talk to it, and the protection is whatever the desktop app does on its side, which the docs I read don't spell out.

The MCP spec itself is wary of localhost as an identity signal. In its discussion of metadata documents it warns that they "cannot prevent localhost URL impersonation by themselves," because an attacker can claim to be a legitimate client and bind to any local port to receive the authorization code. Different mechanism, same lesson: "it's on my machine" is not proof of who is asking.

None of this means the desktop server is unsafe. It means the community workaround trades a vendor's allowlist for an implicit rule that everything on your laptop is trusted. For a single developer's machine, that is often fine. For a shared build box or a machine running several agents with different permissions, it deserves a second look.

The fix worth pushing for

If appeals to "the spirit of MCP" won't move a server operator, what will? Identity.

Client ID Metadata Documents give a client a stable, verifiable name: an HTTPS URL the client controls, a document the server can fetch and cache, and redirect URIs the server must validate against that document. A server that supports them can write a policy that is narrower than "anyone" and wider than "our partners": accept any client whose metadata lives on a domain with a track record, show the client's hostname prominently on the consent screen, and let the user decide. The spec lists "reputation checks for unknown domains" and "restrictions based on domain age or certificate validation" as options alongside allowlists.

That is a policy a server operator can defend and a client author can satisfy without a business-development call. The ask to Figma and every server like it shouldn't be "drop the allowlist." It should be "publish the criteria, and accept clients that meet them."

Put this into practice

The lowest-friction moves, in order:

Check your client's registration path today. If your agent or harness only supports open RFC 7591 registration, it will fail against any server that doesn't offer it. Add pre-registration (a hardcoded or user-entered client ID) as a fallback, which the spec says clients SHOULD support.
Publish a Client ID Metadata Document. Host a JSON file at an HTTPS URL you control with client_id, client_name and redirect_uris, and make sure client_id matches the URL exactly. It costs an afternoon and makes your client legible to servers that adopt identity-based policies.
When you ship an MCP server, decide your admission policy on purpose. If you run a protected server, write down whether you allowlist, check metadata domains, or accept any HTTPS client ID, and put that in your docs next to the server URL.
Treat localhost MCP servers as part of your threat model. List which local servers your agents can reach, which ports they bind, and whether anything else on that machine should be able to call them.
Read the 403. The spec's error table maps 403 to invalid scopes or insufficient permissions. If you're building a client, surface the response body and a next step, the way pi-mcp-adapter now does, instead of a generic failure.

Honest limitations

I'm working from Figma's public docs, one forum thread and one adapter PR. I could not read the original post on X that set off the October 1 discussion, so I can't say what, if anything, Figma announced that day beyond the existing policy. The forum thread is about OpenCode, not Pi; the PR is my evidence that Pi hit the same wall.

I also don't know how Figma's authorization server handles Client ID Metadata Documents, or whether it supports them at all. If it does, the path for new clients may be shorter than the waitlist suggests. And Figma's security reasons for the allowlist may be stronger than anything visible from outside; a vendor that has watched a misbehaving client hammer its API has information I don't.

Finally, the spec version I quoted is 2025-11-25. MCP's authorization rules have moved more than once, and a later revision could change the MAY on open registration or add new admission guidance.

The question to carry forward

MCP did its job. It gave agents and servers a shared way to discover each other, negotiate scopes and bind tokens. What it never claimed to do was decide who gets in, and the October 1 argument is what happens when people assume it did.

So when the next remote server returns a 403, skip the debate about whether that's allowed. It is. Ask the more useful question: what would my client have to prove for you to say yes? Then build the client that can prove it.

Sources: MCP authorization spec 2025-11-25, Figma remote server docs, Figma forum thread, pi-mcp-adapter PR #750, Hacker News discussion.

Medium metadata

Title: Figma's MCP Allowlist Is Spec-Compliant, and That's the Real Problem
Subtitle: The Model Context Protocol tells an agent how to knock. It never promised the door would open.
Tags: MCP, AI Agents, OAuth, API Security, Developer Tools
Canonical URL: import from fervorai.dev