Unlist get_merge_request_commits and get_merge_request_pipelines

What does this MR do and why?

This marks get_merge_request_commits and get_merge_request_pipelines as unlisted MCP tools.

Unlisted tools no longer show up in the MCP tools/list response or the AI Catalog tool picker. They still work through tools/call, so existing callers are not broken.

• get_merge_request_commits is replaced by get_merge_request with include: ["commits"].
• get_merge_request_pipelines is replaced by get_merge_request with include: ["pipelines"].

The MCP server is in Beta and moving to GA. Once GA, the tools/list catalog becomes a compatibility contract. Superseded tools need to stop being advertised before that happens.

Known gap, handled separately

The commits and pipelines facets on get_merge_request are hard-coded to first: 100, so a merge request with more than 100 commits or pipelines is truncated. This is a pre-existing bug in get_merge_request, not something this MR introduces. Adding cursor pagination to those facets is tracked separately and is deliberately out of scope here.

References

• Retirement umbrella: #622712 (closed)
• Pattern established by: !254298 (merged)
• Sibling MR: !255288 (merged)

How to verify locally

bundle exec rspec spec/requests/api/mcp/handlers/list_tools_spec.rb ee/spec/requests/api/mcp/handlers/list_tools_spec.rb ee/spec/models/ai/catalog/mcp_tool_spec.rb

This was also verified end to end on a local GDK over real HTTP JSON-RPC: both tools are gone from tools/list, and both still return real data through tools/call.

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.

🤖 Generated with Claude Code