## Problem With https://gitlab.com/groups/gitlab-org/-/epics/18413 GitLab is providing an official MCP server that is built into the instance. This allows AI tools, which operate as MCP clients, such as Cursor or Claude Code to interact with the GitLab Instance in a more AI-native way then it would happen through our API. Our own agentic features now also start to [support MCP](https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/). We're defining tools such as, e.g. `get_issue`, or some variant that accomplishes the same goal, within the MCP server. The same tool is also available [within the Duo Workflow Service](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/blob/main/duo_workflow_service/tools/issue.py#L280). While this is necessary to get the MCP server, we're also in the process of adding more and more new Tools to the Duo Workflow service which are just there to interact with the GitLab API. It is very likely that, in the long run, most of these tools should also be available in GitLabs official MCP server, which would essentially mean implementing the same tool in two places, doubling the needed effort, and adding twice the chance for bugs and maintenance overhead. In addition to that there are [well-documented](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/issues/1328#note_2652604957) problems with how our GitLab tools are currently set up in the Duo Workflow Service. We run the risk of either doing the same mistakes again, or actually providing superior tools to external AI systems compared to our own. ## Suggested Solution We migrate towards using the official MCP server for any interactions between our Duo Agent Platform's agents and the GitLab instance and replace our current GitLab api specific tools with it. Associated Benefits: 1. GitLab instance specific AI tools 1. only need to be implemented once 1. are implemented in the familiar codebase for most GitLab developers without them needing to learn a new language 1. can be developed without needing to set up separate services 1. automatically be versioned with the GitLab instance version so that only really available tools are presented to the AI. This is a problem with the way tools are currently implemented 2. GitLab's remote MCP server 1. is automatically dogfooded, which would otherwise be tricky since we prefer using only internal AI tools for development 1. automatically gain new tools depending on the needs of the agent platform 3. Agent Platform 1. get's overhauled GitLab tools, which are also battle-tested through other AI solutions. ## Implementation Plan TBD, but the first parts to figure out would likely be: 1. Authentication between Agent Platform and MCP server 2. Ensuring enough available tools on the MCP server