GitLab MCP: create_merge_request reports missing auth while identical PAT succeeds via REST API

[SerheoReutty]

Summary
The GitLab MCP integration can perform read operations successfully (e.g. get_current_user returns the expected user), but create_merge_request fails with an error stating that user authentication / GitLab credentials are required—even though the same Personal Access Token (PAT) successfully creates a merge request when used directly against the GitLab HTTP API with curl.

This suggests a client/MCP wiring or auth-handling bug for mutating tools, not insufficient token scopes on the GitLab side.

Environment
GitLab host (example): https://gitlab.example.com
MCP server (as exposed in the editor): user-gitlab (tool create_merge_request is present in the tool list)
Editor / MCP host: (add product name and version)
Token scopes
The PAT used for integration was created with the following scopes:

read_repository
read_registry
read_virtual_registry
read_api
write_repository
api
These scopes are sufficient for creating merge requests via GitLab’s REST API (notably api).

Observed behavior
get_current_user (or similar read-only MCP tool): works; returns authenticated user profile from gitlab.example.com.

create_merge_request with arguments such as:

projectPath: ours_templates/ansible_roles/user_management (fictitious full project path)
sourceBranch: feature-branch
targetBranch: main
title: e.g. TICKET-1234: Example change in templates/sshd_config.j2
Result: MCP error along the lines of: “User authentication is required for creating merge requests. Please provide your GitLab credentials.” (Also observed when userCredentials is explicitly set to null.)

Same PAT via curl: merge request is created successfully.

Expected behavior
If the integration is configured with a PAT that can create MRs via POST /api/v4/projects/:id/merge_requests, then create_merge_request should succeed using that same configured credential, unless the product intentionally requires inline userCredentials for writes (in which case this should be documented clearly).

Minimal reproduction (GitLab REST – succeeds)
Replace YOUR_TOKEN_HERE with the same PAT configured for MCP. Do not paste a real token into a public issue.

curl --silent --show-error --request POST
--header "PRIVATE-TOKEN: YOUR_TOKEN_HERE"
--data-urlencode "source_branch=feature-branch"
--data-urlencode "target_branch=main"
--data-urlencode "title=TICKET-1234: Example change in templates/sshd_config.j2"
"https://gitlab.example.com/api/v4/projects/ours_templates%2Fansible_roles%2Fuser_management/merge_requests"
The last path segment is the URL-encoded full project path: ours_templates/ansible_roles/user_management → ours_templates%2Fansible_roles%2Fuser_management.

Actual reproduction (MCP – fails)
Server: user-gitlab
Tool: create_merge_request
Same fictitious projectPath, branches, and title as above.
Outcome: authentication error as described, despite PAT working in curl.
Hypothesis
Mutating MCP tools may not receive the same credential as read-only tools, or create_merge_request may require inline userCredentials while other tools use the host-configured token—leading to a misleading error when only host integration is configured.
Request
Please investigate why create_merge_request does not use the configured GitLab PAT when the identical token successfully calls POST https://gitlab.example.com/api/v4/projects/ours_templates%2Fansible_roles%2Fuser_management/merge_requests.

[ttpears]

Fixed in v1.15.1 (npm: @ttpears/gitlab-mcp-server@1.15.1, GHCR image tagged 1.15.1).

Root cause: every write tool handler had an early-exit if (!credentials) throw guard that short-circuited the documented four-step token resolution in getClient(). When the server was configured with GITLAB_TOKEN (the documented full-access fallback for both reads and writes) and no per-call userCredentials were supplied, the guard fired before getClient() could pick the env token — so reads worked but every write returned User authentication is required.... The guard contradicted the design from the 1.14.0 auth refactor; reads were unaffected because read handlers never had it.

Fix: removed the guard from create_merge_request, create_issue, update_issue, delete_issue, update_merge_request, manage_pipeline, create_note, delete_note, update_note, create_broadcast_message, update_broadcast_message, delete_broadcast_message, and the requiresWrite branch of execute_custom_query. getClient() still throws an actionable error if no token at all is configured. See PR #33.

After upgrading, create_merge_request with your existing PAT in GITLAB_TOKEN should behave the same as the curl reproduction in the report. Thanks for the well-detailed issue — the curl-vs-MCP comparison made the diagnosis straightforward.