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_reason helper instead of using one fixed string.
  • There is precedent for this in the same product area. ee/lib/api/orbit/data.rb uses 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 string 403 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.

Edited by 🤖 GitLab Bot 🤖