Skip to main content
Glama

search_groups

Find GitLab groups by name or description using search queries, with options to filter by ownership, access levels, and pagination.

Instructions

Search for GitLab groups

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
searchYesSearch query for groups
pageNoPage number for pagination (default: 1)
per_pageNoNumber of results per page (default: 20)
ownedNoLimit by groups owned by the current user
min_access_levelNoLimit by minimum access level (10=Guest, 20=Reporter, 30=Developer, 40=Maintainer, 50=Owner)

Implementation Reference

  • The actual implementation of the 'searchGroups' function which queries the GitLab API.
    export async function searchGroups(
      query: string,
      page: number = 1,
      perPage: number = 20,
      owned?: boolean,
      minAccessLevel?: number
    ): Promise<GitLabGroupSearchResponse> {
      const params = buildSearchParams({
        search: query,
        page: page.toString(),
        per_page: perPage.toString(),
        ...(owned !== undefined && { owned: owned.toString() }),
        ...(minAccessLevel !== undefined && { min_access_level: minAccessLevel.toString() })
      });
    
      const groups = await gitlabGet<any[]>("/groups", params);
    
      return GitLabGroupSearchResponseSchema.parse({
        count: groups.length,
        items: groups
      });
    }
  • src/server.ts:243-247 (registration)
    Tool handler registration for 'search_groups' which parses arguments and calls the API function.
    case "search_groups": {
      const args = SearchGroupsSchema.parse(request.params.arguments);
      const results = await api.searchGroups(args.search, args.page, args.per_page, args.owned, args.min_access_level);
      return { content: [{ type: "text", text: JSON.stringify(results, null, 2) }] };
    }
  • src/server.ts:69-73 (registration)
    Declaration of the 'search_groups' tool in the MCP server capabilities.
    {
      name: "search_groups",
      description: "Search for GitLab groups",
      inputSchema: zodToJsonSchema(SearchGroupsSchema)
    },
  • Zod schema definition for input validation of the search_groups tool.
    export const SearchGroupsSchema = z.object({
      search: z.string().describe("Search query for groups"),
      page: z.number().optional().describe("Page number for pagination (default: 1)"),
      per_page: z.number().optional().describe("Number of results per page (default: 20)"),
      owned: z.boolean().optional().describe("Limit by groups owned by the current user"),
      min_access_level: z
        .number()
        .optional()
        .describe("Limit by minimum access level (10=Guest, 20=Reporter, 30=Developer, 40=Maintainer, 50=Owner)")
    });
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether this is a read-only operation, what authentication is needed, rate limits, pagination behavior beyond schema hints, or what the response format looks like. 'Search for' implies a query operation, but lacks detail on scope or limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise - a single sentence that directly states the tool's purpose without any fluff. It's front-loaded with the essential information, making it efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 5 parameters and no output schema, the description is insufficient. It doesn't explain what the search returns, how results are structured, or any behavioral aspects like pagination handling. With no annotations and no output schema, the description should provide more context about the operation's behavior and results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, providing good documentation for all parameters. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline for high schema coverage without compensating with extra context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Search for') and resource ('GitLab groups'), making the purpose immediately understandable. It distinguishes this from sibling tools that create, update, or delete resources, though it doesn't explicitly differentiate from other search tools like search_issues or search_repositories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. While the name implies searching groups specifically, there's no mention of when this is preferred over other search tools or list operations, nor any prerequisites or constraints for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TheRealChrisThomas/gitlab-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server