HTTP Request to Figma MCP Fails with 'Method not found' on Self-Hosted OCI Docker Install

Hello everyone,

I’m having a persistent issue trying to connect to the Figma MCP server from my self-hosted n8n instance, and I’ve hit a wall after extensive troubleshooting. I’m hoping someone in the community might have an idea.

My Goal:
To send a POST request to the Figma MCP API endpoint at https://mcp.figma.com/mcp.

My Environment:

  • n8n Version: 1.113.3 (Self Hosted)

  • Running n8n via: Docker

  • Operating System: An Oracle Cloud Infrastructure (OCI) VM running Ubuntu.

The Problem:
I am using the standard HTTP Request node with the following configuration:

  • Method: POST

  • URL: https://mcp.figma.com/mcp

  • Authentication: Header Auth with a valid Bearer token.

  • Headers: Content-Type set to application/json.

  • Body: A valid JSON-RPC request like {“jsonrpc”: “2.0”, “method”: “list_pages”, “id”: 2, “params”: {“file_key”: “my-file-key”}}

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32601,
    "message": "Method not found."
  },
  "id": 2
}

What I’ve Already Ruled Out:

This is where it gets confusing. I’m sure my configuration is correct because of these two tests:

1. Successful curl Test from the OCI Server
I SSH’d directly into the OCI virtual machine where my n8n Docker container is running. From there, I ran a curl command with the exact same URL, headers, and body. It worked perfectly. The server connected and responded correctly.

This proves that:

  • My OCI server’s networking (firewall, egress rules) is correct.

  • My Bearer token is valid.

  • The Figma server is reachable from my OCI instance.

Here is the successful verbose output from the curl command:```

  • Trying 13.225.5.112:443…

  • Connected to mcp.figma.com (13.225.5.112) port 443 (#0)
    … (SSL handshake successful) …

  • SSL certificate verify ok.

POST /mcp HTTP/2
Host: mcp.figma.com
authorization: Bearer figd_q63Wn…
content-type: application/json

< HTTP/2 200
< content-type: application/json; charset=utf-8
<
{“jsonrpc”:“2.0”,“error”:{“code”:-32601,“message”:“Method not found.”},“id”:null}

2. Successful Test with Webhook.site
I then pointed my n8n HTTP Request node to a temporary URL from webhook.site. The test showed that n8n is sending a perfectly formed request. The authorization and content-type headers were present and correct, and the JSON body was sent exactly as configured.


My Question:

Given that a curl command from the server works, and a test to webhook.site shows n8n is sending the correct data, why would the HTTP Request node still result in a “Method not found” error from the Figma server?

It seems like there’s a very specific issue happening only when the request comes from the Node.js/Axios process inside the n8n Docker container, which is different from the curl binary on the same machine. Could this be a subtle networking issue with Docker on OCI, or perhaps a specific SSL/TLS negotiation problem?

I’ve hit a dead end and would be grateful for any ideas or suggestions. Thank you

Maybe i am not understanding correctly, but it looks like in your description that you are in fact getting a correct response from Figma and it tells you that list_pages is not a method that exists?

If that is misunderstood then i would look to the following :slight_smile:

Sending the request from the Ubuntu server is not necessarily the same as from the docker container.
Maybe you could try to go all the way into the actual docker container and try to execute the curl request from there (ie exec n8ncontainer). You can install curl if its not already installed, dont remember if its included.

By doing this you could determine if its likely a Docker related networking issue (curl fails from inside container too), or if its more likely an n8n/Node.js/Axios specific issue (curl works from inside container).

If its the latter, i would look to sniff out exactly how the outgoing requests look like and compare details, could be something mundane like useragent or some misconfigured headers, perhaps http version, although it sounds like you have already investigated this.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.