Unlist the get_workitem_notes MCP tool superseded by the notes facet

What does this MR do and why?

The GitLab MCP server advertises its tool catalog via tools/list. At GA, that advertised catalog becomes a compatibility contract, so tools that have been superseded need to stop being advertised before GA. This MR marks the GraphQL-backed get_workitem_notes MCP tool as unlisted, since it is superseded by the notes facet of the get_work_item MCP tool (calling get_work_item with notes included).

Unlisting hides the tool from tools/list and from the AI Catalog tool picker, but it stays fully callable through tools/call, so existing callers keep working while they migrate to get_work_item.

Changes:

  • unlisted? overridden to return true in app/services/mcp/tools/work_items/get_work_item_notes_service.rb.
  • Docs updated in doc/user/model_context_protocol/mcp_server_tools.md with an "Unlisted in GitLab 19.4" history entry and a supersession note pointing to get_work_item.
  • CE and EE list_tools specs updated to remove get_workitem_notes from expected annotations, and the retired-tools context extended.
  • Added a unit example asserting unlisted? is true.

This MR is stacked on Unlist the create_issue MCP tool superseded by save_work_item: it targets that MR's branch, so the diff shows only this MR's commit, and GitLab retargets it to master automatically when that MR merges.

References

How to verify locally

  • bundle exec rubocop clean.
  • 40 examples green across the service spec and the CE/EE list_tools specs.
  • GDK e2e over real HTTP JSON-RPC: tools/list contains neither retired tool; tools/call get_workitem_notes still returns the notes connection for a live work item.
Edited by Tian Gao

Merge request reports

Loading
Loading