Trying figma mcp server with cline extension

Hi ​@pjaroliya, 

Thanks for the detailed report.

I understand you're running into an issue with the Cline integration where it fails because:

• Figma remote MCP server is returning a plain-text 403 Forbidden response.
• Cline expects a JSON-formatted error payload.

We checked on our team, and the “403 Forbidden” response typically indicates an issue with authorization or permissions.

Could you please double-check that the user account you're authenticating with on the Remote MCP server is the same one that has access to the Figma file?

You can run a whoami tool call to verify the identity of the currently logged-in account on the MCP server. Tools and prompts > whoami (remote only)
 

Thanks,

Hi,                                                                                                            
Thank you for the response, but the account/permissions suggestion does not apply here. The issue occurs at the protocol level — before any authentication can take place, and therefore before any token or account context exists.  
Let me clarify the exact failure sequence: What actually happens (step by step)

1. Cline sends an unauthenticated POST https://mcp.figma.com/mcp with an MCP initialize request — this is the standard first step in the Streamable HTTP transport, as specified by the MCP protocol.
2. Figma responds with HTTP 403 Forbidden, Content-Type: text/plain, body: "Forbidden".
3. Cline attempts to parse the body as JSON (required by MCP/JSON-RPC spec) and throws: SyntaxError: Unexpected token 'F', "Forbidden" is not valid JSON
4. The OAuth flow never starts. The "Connect" / OAuth button in Cline never appears because the client crashed before reaching the auth discovery step.

This is not a "wrong account" problem. There is no account involved yet — the failure happens before any credentials are presented.                                                    
                                                                                                    
Root cause: Wrong HTTP status code + wrong Content-Type
The MCP Streamable HTTP spec (and RFC 6750) is explicit about how auth challenges must be returned:

• A 401 tells the client "you need to authenticate — here's how." It triggers the OAuth discovery flow.
• A 403 tells the client "you are authenticated but not permitted." It is a terminal rejection — no OAuth flow is initiated.                                                           

Figma's server is returning 403 when it should return 401, and is returning plain text when it must return JSON. This is what breaks strict MCP clients like Cline.                    

Why other clients appear to work:
Clients like Cursor and Codex CLI implement their own auth wrappers or handle non-JSON 4xx responses leniently (i.e., they silently swallow parse errors and retry with a token). Cline strictly follows the MCP spec and does not special-case Figma's non-compliant responses. This is not a Cline bug — Cline's behavior is correct per the spec.                          
I also verified this with Vercel's MCP server (https://mcp.vercel.com ), which correctly returns HTTP 401 + WWW-Authenticate → the OAuth flow completes and the button appears in Cline. The Figma endpoint is the only one returning 403 text/plain.

Specific fix requested
Please fix https://mcp.figma.com/mcp to:

1. Return HTTP 401 (not 403) when no/invalid auth is present on the initial request
2. Include a WWW-Authenticate: Bearer realm="...", resource_metadata="<OAuth metadata URL>" header so clients can discover the OAuth server                                          
3. Return error bodies as application/json, not text/plain

This is a server-side fix. No change is needed on the client or in the user's Figma account.                                                                                           

Reproducible test (no Cline needed)                                                                                                        

curl -v -X POST https://mcp.figma.com/mcp \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{}},"id":1}'      

                                                             
Expected: HTTP 401 + WWW-Authenticate header + JSON body
Actual: HTTP 403 + Content-Type: text/plain + body "Forbidden"
This curl command requires zero credentials and reproduces the issue in full.

I'm happy to provide additional info needed. This is a quick fix on the server side and would unblock all strict MCP clients immediately.

Thanks    

Hi ​@pjaroliya! Stepping in for ​@Junko3 here.

Thank you so much for all the detail and clarification - I’ve taken this information to the team so they can take a look. In the meantime there are a couple things you can try that might help so you can start using the MCP:

1. You’ve been using the remote MCP server, right? I would try the desktop MCP server. If you already have the desktop app installed, then make sure it’s updated to the newest version.
2. You’ll be forgoing the streamable HTTP transport for now, but you could try using the configuration shown in our developer docs for VS Code:

Remote Server:

{
   "inputs": [],
   "servers": {
     "figma": {
       "url": "https://mcp.figma.com/mcp",
       "type": "http"
     }
   }
}

Desktop Server:

{
   "servers": {
     "figma-desktop": {
       "type": "http",
       "url": "http://127.0.0.1:3845/mcp"
     }
   }
 }

Let me know if those work for you, and when I have more information I’ll reply again.

thanks ​@adamsmasher for looking into it, appreciate it. I’ll wait for your progress on this.

Right now I’m trying to get the Figma MCP remote server up and running. Figma is already our standard design tool, so the goal is to help developers get familiar with it and benefit from the official MCP. At the moment, we’re using a few open-source Figma MCP options.

Regarding the desktop server suggestion: I get the idea, but scaling that to a large group is pretty tough. Asking everyone to install and run something locally adds friction, especially compared to a remote MCP setup.