Need help configuring GitLab MCP server (Getting 404 and Token errors)

[francinii]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Hello Dify team and community!

I am currently trying to configure a GitLab MCP tool in my Dify instance (hosted on AWS), but I'm struggling with the connection and authentication.

My Setup:

• Dify version: [Insert your Dify version here, e.g., 1.14.0]
• Deployment: AWS
• MCP Tool: Trying to use the GitLab MCP server integration

What I have tried:

1. In the "Edit MCP Server (HTTP)" configuration, I set the Server URL to https://gitlab.com/api/v4/mcp (or the standard GitLab API).
2. For authentication, I have tried both using a Bearer token (GitLab Personal Access Token) and OAuth (Client ID and Client Secret).

The Errors:
Depending on the attempt, I get the following errors:

• Failed to connect to MCP server: code=32600 message='MCP server URL returned 404 Not Found: https://gitlab.com/api/v4/mcp — verify the server URL is correct and the server is running'
• Failed to connect to MCP server: Authentication failed - no token received

My Question:
I am starting to realize that GitLab itself might not host a native MCP endpoint and I might need to run a separate MCP SSE proxy/bridge (like @zereight/mcp-gitlab) on my AWS server.

Could someone guide me on the correct architecture for this?

1. Do I need to spin up a separate Node.js/Python proxy container in AWS just for this GitLab tool?
2. If so, how do I properly pass the authentication (PAT) so Dify recognizes it as "Authorized"?

Any examples or guidance on how to properly set up the GitLab MCP bridge for a cloud-hosted Dify instance would be greatly appreciated! Thank you!

2. Additional context or comments

Some images about my current set up

[cookesan]

Do not point Dify at the GitLab REST API URL as the MCP server.

Dify's MCP provider stores a server URL plus optional headers/OAuth credentials, validates that URL as HTTP(S), then connects with its MCP client and calls list_tools(). The MCP client chooses SSE or streamable HTTP based on the URL path, so the URL needs to be an MCP server endpoint, not a normal API base path. A 404 from https://gitlab.com/api/v4/mcp fits that mismatch.

For the architecture you described, run a GitLab MCP bridge somewhere your AWS-hosted Dify instance can reach, configure that bridge with the GitLab PAT if the bridge is the component calling GitLab, then set Dify's Server URL to the bridge's MCP HTTP/SSE endpoint.

Only put an Authorization: Bearer ... header in Dify if the MCP bridge itself expects Dify to authenticate that way. Dify's OAuth fields are for the MCP server's auth flow; they do not turn the GitLab REST API into an MCP endpoint.

[CedricConday]

Building on @cookesan — the 404 is the tell that the URL is a REST endpoint, not an MCP one. Two GitLab specifics:

• Point Dify at GitLab's MCP endpoint, not the REST API. Recent GitLab ships an MCP server; use that MCP route (check your GitLab version's MCP docs for the exact path), not /api/v4/projects/.... A normal REST path has no MCP handshake → 404.
• Token scope: "token errors" usually means wrong PAT scope — GitLab's MCP needs an api-scoped token; a read_api-only one authenticates but gets rejected. Pass it as Authorization: Bearer <PAT> in Dify's MCP provider config.

Quick isolation: curl the MCP URL with an initialize JSON-RPC body + bearer header — if that returns a proper MCP response, Dify will too; if it 404s, the URL's still wrong.