## Summary Move **MCP server** configuration out of the **Duo Agent Platform (DAP)** settings into its own explicit **“MCP server” availability setting**, while preserving existing behavior and respecting licensing and kill-switch constraints. This issue covers: - Adding a dedicated **MCP server** setting at instance / top-level group level. - Defining and implementing the **effective gating logic**. - Running a **data migration** to safely map **current states → new setting**. - Updating docs and UI copy so customers understand **which prerequisites** are required. --- ## Release notes You can now enable or disable the GitLab MCP server independently from Duo Agent Platform settings, giving you finer control over how external tools connect to your GitLab instance or group. This means you can let other tools access GitLab as an MCP server without turning on Duo Agent Platform, or keep the MCP server off while still using Duo Agent Platform features. ### Background & Problem Today, MCP server behavior is controlled implicitly by a combination of: - **Duo Core add-on** (entitlement / seats). - **Duo availability** (kill switch for AI features). - **Experimental & beta Duo features** (because MCP server is currently beta). - Internally, MCP server is surfaced under the Duo Agent Platform settings area. This leads to: - **Confusing UX**: customers discover MCP server via **Duo Agent Platform** docs and settings, even though server is conceptually “infrastructure” rather than a DAP feature. - **Coupling to Duo Core / Duo availability**: You cannot conceptually choose: - “MCP server on, DAP off” or - “DAP on, MCP server off” even though those are reasonable product configurations. - **Docs confusion**: internal and external documentation have previously mixed or conflated “Duo Core” vs “Duo availability”, and it’s not obvious which settings actually gate MCP. - **Governance gap**: there is no clear, first-class **“MCP server availability”** toggle for admins that reads like: “Let other tools use GitLab as an MCP server.” We want to: - Treat MCP server as a **separate, first‑class capability** with its own availability toggle. - Remove the **hard wiring** between MCP server and DAP/Duo availability, while still allowing licensing rules to be enforced at the subscription layer. - Preserve **current effective behavior** during migration (no customer regressions). --- ## Goals - Add a dedicated MCP server availability setting at: - GitLab.com: top‑level group Duo settings page. - Self‑managed / Dedicated: instance Duo settings page. - Allow customers to: - Enable MCP server without enabling DAP. - Enable DAP without enabling MCP server. - Keep any licensing constraints (e.g., requiring a specific tier or add‑on) as entitlement checks, not UI‑level coupling to Duo Core / Duo availability. - Run a data migration that: - Infers “effective MCP server is on” from today’s combination of Duo Core, Duo availability, and beta features. - Seeds the new MCP toggle so there is no behavioral regression at rollout. Out of scope (for this issue): - Changing the **underlying entitlement model** for Duo Core or MCP. - Changing **DAP** behavior beyond removing MCP configuration from its UI section. - Adding **per-project** or **per-subgroup** MCP server toggles (this is about the existing top-level / instance scope). --- ### Current Behavior¹ MCP server is effectively available only when all of the following are true (based on internal discussions and recent clarifications): - The namespace has Duo Core add‑on - Duo availability is not `Always off` - Experimental & beta GitLab Duo features are turned on (while MCP is beta) Informally, this is: ```text effective_mcp_enabled_today = has_duo_core_addon AND duo_availability != "always_off" AND experiment_features_enabled # (plus any existing internal MCP wiring under DAP) ``` - Duo Core is an **add-on** that provides a set of Duo features. - Those Duo features can be **enabled/disabled via Duo availability**. - **Both** must be “on” for MCP to work: - The namespace must have **Duo Core add-on**. - The namespace must have **Duo availability enabled**. - If the namespace doesn’t have Duo Core, it can’t effectively use the Duo availability setting for those features. _¹_[_Reference_](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/212102#note_3092024803) --- ## Proposed Behavior - New “MCP server” setting Add a dedicated **MCP server** block on the GitLab Duo settings page: - **GitLab.com**: `/groups/:top_level_group/-/settings/configuration` - **Self-managed / Dedicated**: `/admin/` (instance-level) **UI concept (top-level group)** - **Section title:** `MCP server` - **Checkbox / toggle:** - Label: `Allow other tools to use this GitLab group as an MCP server` - Description (example): > When enabled, other tools that support Model Context Protocol (MCP) can connect to GitLab and access group data according to your Duo and project permissions. Key principles: - This toggle is independent of the DAP section and its toggles. - This toggle is independent of Duo availability and Duo Core from a configuration perspective: - Admins can set: - MCP server On, DAP Off. - MCP server Off, DAP On. --- ### Data Model & Migration > **Important:** This issue describes the logical migration. Exact column names / models should be confirmed against current implementation (`NamespaceSettings`, etc.). #### 1. New persistent field Introduce a persistent flag for MCP server availability at the appropriate level: - **GitLab.com (top-level group):** - Candidate: `namespace_settings.mcp_server_enabled` (boolean) - **Self-managed / Dedicated (instance):** - Candidate: `application_settings.mcp_server_enabled` (boolean) Exact naming can differ; the key is: - It should be **independent** from DAP-specific flags. - It must be **scoped** similarly to Duo availability and Duo Core settings: - Instance-level on SM/Dedicated. - Top-level group level on GitLab.com. #### 2. Inputs for migration For each **namespace / instance** that supports MCP server today, we’ll inspect: - `duo_core_features_enabled` (top-level group or instance) - `duo_availability` (enum: `on_by_default`, `off_by_default`, `always_off`) - `experiment_features_enabled` (top-level group / instance) - Any existing **MCP / DAP-specific internal flag**, e.g.: - `duo_workflow_mcp_enabled` (if already present as part of DAP) We should treat **`duo_workflow_mcp_enabled`** as **authoritative if it already exists**. Where it doesn’t, we can approximate behavior from the core/beta/availability combination. #### 3. Migration table (existing → new MCP setting) We want the new MCP server toggle to start as On everywhere that MCP is effectively usable today, and Off otherwise. Treat `On by default` and `Off by default` as both “allowed in principle” (subject to resource‑level overrides) and `Always off` as “hard disabled”. | Duo availability | Duo Core add-on | Beta/exp features | Existing MCP/DAP flag (if any) | New `mcp_server_enabled` (initial) | Notes | |------------------|-----------------|-------------------|--------------------------------|------------------------------------|-------| | On by default | On | On | true | **true** | Fully compatible and explicitly enabled today. | | On by default | On | On | false/NULL | **true** | MCP effectively works; migrate to true to preserve behavior. | | Off by default | On | On | true | **true** | Top-level available but children may override; preserve behavior. | | Off by default | On | On | false/NULL | **true** | Same as above; allow MCP where Duo is enabled. | | Always off | On | On | (any) | **false** | Kill switch: MCP must remain off; disable MCP toggle in UI. | | On/Off by default | Off | On | (any) | **false** | No Duo Core seats: MCP should not be usable. | | On/Off by default | On | Off | (any) | **false** | MCP is beta; keep off as long as beta is disabled. | | Always off | Off | Off | (any) | **false** | Everything off. | --- ### Docs **Update **[**MCP server docs**](https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_server/): - Describe MCP server as an independent capability with its own availability setting. - Clarify that customers can enable MCP server without enabling DAP, and vice versa. ---