gitlab-api

Get group vulnerabilities

gitlab_get_group_vulnerabilities

Read-onlyIdempotent

Retrieve a GitLab group's security vulnerability findings with pagination and optional filters, so you can review and track risks at the group level.

Instructions

Get a group's security vulnerability findings (Ultimate).

GET /groups/{group_id}/vulnerability_findings

Args: **kwargs: group_id (required); optional pagination.

Returns: Response: wrapper containing the original response and the parsed vulnerability findings (list of dicts).

Raises: MissingParameterError: If group_id is missing. ParameterError: If invalid parameters are provided.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "gitlab_get_group_vulnerabilities"
  }
}

Input Schema

Name	Required	Description	Default
`data`	No
`page`	No
`group_id`	No
`per_page`	No
`max_pages`	No
`project_id`	No
`package_manager`	No
`vulnerability_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv27.3.20Nov 7, 2026

removedInput schema / properties / api_parameters

Removed value: -{
-  "anyOf": [
-    {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null
-}

First observedv27.3.13Oct 25, 2026

TDQS

B3.3/5.0

Behavior4/5

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

Annotations already cover the read-only, idempotent, non-destructive profile, so the description's added value is the Ultimate licensing requirement, the raw endpoint, and the two exception types (MissingParameterError, ParameterError) that tell the agent how failures surface. It stops short of describing pagination defaults or the max_pages behavior, which are the main behavioral unknowns left.

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

Conciseness3/5

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

The purpose line is front-loaded and the Args/Returns/Raises structure is scannable, but the '**kwargs:' Python signature leaks into prose and 'Response: wrapper containing the original response and the parsed vulnerability findings' is wordy. Nothing is egregiously wasteful, but several lines could be tightened.

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

Completeness3/5

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

With no output schema, it correctly explains the return value and error surface, which is genuinely helpful. However, for an 8-parameter filtered-list tool with 0% schema documentation, leaving most filters and the pagination/max_pages semantics unexplained leaves the definition short of what an agent needs to call it correctly.

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

Parameters2/5

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

Schema description coverage is 0% across 8 parameters, so the description carries the full burden, yet it only names group_id (as required) and gestures at 'optional pagination'. It says nothing about project_id, vulnerability_id, package_manager, or the opaque 'data' object, and its 'group_id (required)' claim conflicts with a schema that marks nothing required.

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 first sentence gives a specific verb and resource ('Get a group's security vulnerability findings') and adds the Ultimate tier requirement plus the underlying endpoint. The word 'group' implicitly separates it from gitlab_get_project_vulnerabilities, but no sibling is named, so an agent must infer the scope distinction.

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

Usage Guidelines3/5

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

Usage is only implied by the resource name; there is no explicit statement of when to call this versus gitlab_get_project_vulnerabilities or gitlab_get_vulnerability, and no prerequisites such as the Ultimate license being checked by the caller. The '(Ultimate)' note is the one real gating hint.

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

Deploy Server