Unlist the get_merge_request_conflicts MCP tool
What does this MR do and why?
Unlists the get_merge_request_conflicts MCP tool, superseded by get_merge_request with include: ["conflicts"].
The tool stops appearing in tools/list so agents stop discovering it, but stays registered and callable. Everything that already references the name keeps working: stored Catalog agents, Governance rules, and any caller still using the old name.
This follows the same pattern as !254298 (merged), !254299 (merged), !254571 (merged), !255288 (merged) and !255298 (merged).
References
- Parent issue: #622712 (closed)
- Issue to remove tool: #628612 (closed)
- Full deprecation will be tracked in #609451
- Proposed to replace the alias approach in !252513 (closed). See below for why.
Why this replaces the alias approach in !252513 (closed)
!252513 (closed) retired the same tool by turning it into an alias of get_merge_request. Testing that branch in a local GDK showed the alias removes the name from the tool registry entirely, which breaks three things unlisted leaves intact:
| Alias | Unlisted | |
|---|---|---|
Manager#list_tools has the name |
no | yes |
PRIVILEGE_GROUP_FOR / rulable_tool_names |
nil / false |
:read_only_gitlab / true |
| Governance row in Tool management | gone | present, existing rule still enforced |
Existing Ai::ToolRule for the name |
invalid, unenforced and uneditable | valid |
Ai::Catalog::McpTool.find_by_name |
nil |
resolves |
| Agent holding the tool renders as | raw name, struck through | normal title |
The governance effect was the blocker: a rule written against the tool name stayed in ai_tool_rules but failed validation with "is not a known tool name", so it was neither enforced nor editable, and its row disappeared from Tool management.
Thanks to @jessieay for catching the governance and Catalog problems on !252513 (closed).
Screenshots or screen recordings
No UI changes.
How to set up and validate locally
The point of unlisting is that the tool disappears from discovery while everything that already references it keeps working, so the checks below cover both halves.
You need a GDK with the MCP server enabled, and a merge request that genuinely has
conflicts. Cached merge_status lies, so pick one by resolving it rather than by the flag:
# rails console
MergeRequest.where(merge_status: "cannot_be_merged").limit(25).each do |mr|
next unless mr.has_complete_diff_refs? && !mr.branch_missing?
files = MergeRequests::Conflicts::ListService.new(mr, allow_tree_conflicts: true).conflicts.files
next if files.empty?
puts "#{mr.project.full_path}!#{mr.iid} -> #{files.map(&:our_path).join(', ')}"
rescue StandardError
next
end1. It is hidden from agents, but still registered
# rails console
name = "get_merge_request_conflicts"
Mcp::Tools::Manager.new.list_tools[name].unlisted? # => true
Ai::Catalog::McpTool.find_by_name(name).present? # => true (catalog can still resolve it)2. It no longer appears in tools/list
In GitLab Duo Chat, ask what merge request tools are available. get_merge_request should be
offered and get_merge_request_conflicts should not.
3. It is still callable under the old name
Ask Duo Chat for the conflicts on the merge request you found above, naming the old tool:
Use the get_merge_request_conflicts tool on merge request in project
It should return the conflicting file paths with raw <<<<<<< / ======= / >>>>>>> markers,
in the same plain-text # File: format as before this change.
4. Governance still sees it
Go to Settings > GitLab Duo > Governance > Tool management for a group and search
conflicts. The table paginates and is not alphabetically sorted, so search rather than scroll.
- The Get Merge Request Conflicts row is still listed
- Change its Web access to Always ask, save, and confirm it persists on reload
5. An existing Catalog agent still works
Create an agent in the AI Catalog with the tool selected, then run it in Agentic Chat against the same merge request.
- The tool renders with its title, not struck through or greyed out
- Executing the agent returns real conflict content
Known gap, handled in a follow-up MR: the tool is still offered when building a new agent,
because the built-in catalog entry is a separate namespace that unlisted? does not reach.
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.