Accept issue and epic URLs for MCP work item resolution

Tian Gaorequested to merge
618070-accept-issue-epic-work-item-urls into master

What does this MR do and why?

The shared UrlParser work-item pattern only matched .../-/work_items/<iid> URLs, but the URLs agents actually hold are mostly /-/issues/<iid> (project) and /-/epics/<iid> (group). Those were rejected with "Invalid work item URL format".

This MR widens WORK_ITEM_URL_PATTERN to admit all three forms. Resolution is unchanged: the same parent-path + iid lookup through the same permission-scoped WorkItems::WorkItemsFinder, uniform not-found behavior preserved.

Because the change lives in the shared concern, all five URL-resolving work-item tools pick it up: get_work_item, get_workitem_notes, create_workitem_note, link_work_items, and save_work_item's update path. (The tracking issue named two tools; the shared concern generalizes it, which is the issue's stated intent.)

Also drops the /-/work_items/-only caveat from get_work_item's url description and docs.

Closes #618070 (closed)

Why /-/epics/<iid> resolves directly
  • Unified epics share the group-level issues iid counter (ee/app/models/ee/epic.rb overrides internal_id_scope_usage to :issues), and epic sync copies epic_params[:iid] = work_item.iid.
  • GitLab itself resolves /-/epics/<iid> by group + iid: Groups::EpicsController finds by iid and redirects to the work item route.
  • Project /-/issues/<iid> is the same table as work items.
  • The EE spec resolves a real epic through its /-/epics/ URL and asserts iid equality empirically.

Verification

  • spec/services/mcp/tools/concerns/url_parser_spec.rb (new parse + resolution examples for both forms, plus a negative example for /-/merge_requests/), spec/services/mcp/tools/work_items/get_work_item_service_spec.rb (schema lock), ee/spec/services/mcp/tools/work_items/get_work_item_tool_spec.rb (epic-URL end-to-end through the tool): 65 examples, 0 failures; RuboCop clean.
  • Process note: branch authored via the Commits API because gitlab.com's git-over-HTTPS plane is currently load-shedding; changes verified locally against a master-equivalent file overlay. A GDK MCP round-trip will be posted as a follow-up comment once the git plane recovers.

Merge request reports