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

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
end

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

Edited by Terri Chu

Merge request reports

Loading
Loading