Create aggregated search MCP tool

What does this MR do and why?

Create an aggregated search MCP tool which exposes global, group and project search rest API to MCP tool. Users can send over params and the right tool will be called based on what is provided. This is needed to help reduce tool count (do not need 3 search tools to search at all levels). The descriptions for input params is also built based on what is turned on for a GitLab instance.

Scopes availability on an instance is controlled by feature availability and application settings which can turn off global searches for a scope. For example, on GitLab.com global code search is turned off but it is on by default for SM instances with advanced search enabled. The available scopes for each search type:

• basic search
• advanced search
• exact code search

Ai Summary

This merge request adds a new search aggregation feature to GitLab's AI assistant tools. The main change creates a unified search tool that can search across different levels (entire GitLab instance, specific groups, or individual projects) by automatically routing requests to the appropriate underlying search API based on the provided parameters.

The code introduces an "AggregatedService" base class that acts as a smart dispatcher - when users make a search request, it examines the parameters (like group_id or project_id) to determine which specific search tool to use, then forwards the request appropriately. This replaces the previous approach where users had to know exactly which search endpoint to call.

Additional changes include:

• Updated code style rules to allow the new tool files
• Enhanced search functionality to support notes/comments searching
• Improved API documentation to clarify that search works at group and project levels, not just globally
• Added comprehensive test coverage for the new search scoping logic
• Updated the user documentation to reflect the expanded search capabilities

The overall effect is that GitLab's AI assistant now provides a more intuitive search experience - users can simply specify what they want to search for and optionally where to search, without needing to understand the underlying API structure.

References

• Related to #571132 (closed)
• Inspiration proof of concept MR: Draft: Allow defining MCP route aggregators (!202765 - closed)

Screenshots or screen recordings

global search

I had a typo and it ran a group search, then a global

I intended to run global search in this one

group search

project search

Before	After

How to set up and validate locally

I used MCPJam to test this out locally, you'll need a few feature flags on

• oauth_dynamic_client_registration
• mcp_server

I would recommend testing this with/without advanced search enabled:

• setup elasticsearch/advanced search in gdk
• turn advanced search on/off in admin - general - search settings

test all three aggregated services by providing:

• no group_id or project_id <-- this should hit global search api
• group_id <-- this should hit group search api
• project_id <-- this should hit project search api

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.