MCP 403 response message is wrong for GitLab.com users with no enabled namespace
Problem
The MCP server API at /api/v4/mcp returns 403 Forbidden with the message MCP server disabled in two different scenarios.
On GitLab Self-Managed, an administrator can turn the MCP server off with an instance setting. In that case the message is accurate.
On GitLab.com, the refusal happens when a user belongs to no top-level group that has MCP turned on. For that user, the message is wrong. Nothing is disabled across the instance. A group owner must turn MCP on for the group, but the message does not say so.
The troubleshooting page explains both causes. It tells the reader to check the denial_reason field in the mcp.log file. A GitLab.com user cannot read that log, so the guidance only helps a self-managed administrator.
Proposal
- Derive the message text from the existing
mcp_denial_reasonhelper instead of using one fixed string. - There is precedent for this in the same product area.
ee/lib/api/orbit/data.rbuses a namespace specific message for a similar refusal. - The current message is pinned by a test assertion in
ee/spec/requests/api/mcp/base_spec.rb. It expects the exact string403 Forbidden - MCP server disabled. That test needs updating too.
This is a follow-up from !255443 (merged), which changed this response from 404 Not Found to 403 Forbidden.
Open question
A more specific message tells the caller more about how the instance or the group is set up. Someone should confirm that this extra detail is acceptable to share.