## 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. --- ### 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. ---