gitlab-api

Download repository package

gitlab_download_repository_package

Read-onlyIdempotent

Downloads a specific package file from a GitLab project repository using project, package name, version, and file name, returning raw package data for local use or deployment.

Instructions

Download a repository package for a specific project.

Args: **kwargs: Additional parameters for the request (e.g., project_id, package_name, package_version, file_name).

Returns: Response: A wrapper containing the original response and the raw package file data.

Raises: MissingParameterError: If the project_id, package_name, package_version, or file_name 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_download_repository_package"
  }
}

Input Schema

Name	Required	Description	Default
`ref`	No
`page`	No
`sort`	No
`select`	No
`status`	No
`group_id`	No
`per_page`	No
`file_name`	No
`max_pages`	No
`package_id`	No
`project_id`	No
`package_name`	No
`package_type`	No
`package_version`	No
`include_versionless`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv27.3.20Nov 7, 2026

removedInput schema / properties / api_parameters

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

changedInput schema / properties / page / default
```
Previous value: -1New value: +null
```
changedInput schema / properties / per_page / default
```
Previous value: -100New value: +null
```

First observedv27.3.13Oct 25, 2026

TDQS

C2.9/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds real value in the Returns and Raises sections: the response wraps the original response plus raw package file bytes, and missing required identifiers surface as MissingParameterError rather than a generic failure. It stops short of describing permissions or size limits for large binaries.

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

Conciseness4/5

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

The one-line purpose is front-loaded and the Args/Returns/Raises structure is easy to scan. The Args block is vague ('**kwargs: Additional parameters ... (e.g., ...)') and wastes a line that could carry firm required-argument names or the meaning of the extra filters.

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 15-parameter tool with no output schema, the description is thin: it explains the return shape and error types, which is good, but leaves most of the surface unexplained and does not resolve how the four identifier arguments relate to package_id or package_type, nor whether the pagination-style parameters matter for a download.

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 15 parameters, so the description must compensate, yet it only names four (project_id, package_name, package_version, file_name) and gives no format or meaning for them. Eleven parameters (ref, page, sort, select, status, group_id, per_page, max_pages, package_id, package_type, include_versionless) are unexplained in both schema and description, and the description asserts the four identifiers are required while the schema marks every parameter nullable with default null.

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 states a specific verb and resource: 'Download a repository package for a specific project'. That distinguishes it from the sibling gitlab_get_repository_packages (list) and gitlab_publish_repository_package (upload), both of which are visible in the sibling list, so an agent can select it without opening schemas.

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?

There is no when-to-use guidance, no prerequisites (auth scope, package registry enabled), and no named alternatives such as gitlab_download_release_asset for release assets. The agent must infer that this is the operation for package registry artifacts and that the listing tool should be used first to discover the exact package name and version.

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

Deploy Server