Skip to main content
Glama
Sign In
gitlab mcp

gitlab mcp

by zereight
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_repository_tree

Read-only

List files and directories in a GitLab repository, optionally by path, branch or tag, and recursive traversal, to inspect repository structure.

Instructions

List files and directories in a repository.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>"
    },
    "name": "get_repository_tree"
  }
}

Input Schema

NameRequiredDescriptionDefault
refNoBranch or tag. Defaults to the default branch.
pageNoOffset page number from 1 (items + next_page)
pathNoPath inside the repository
jmespathNoOptional JMESPath expression filtering the JSON result before return.
per_pageNoItems per page
recursiveNoRecursive tree
page_tokenNoKeyset token from the previous next_page_token
paginationNoUse keyset for large trees (items + next_page_token). Omit both page and pagination for the legacy array (deprecated).
project_idYesProject ID or URL-encoded path

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv2.3.22
    • addedInput schema / properties / page
      Added value: +{
+  "description": "Offset page number from 1 (items + next_page)",
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}
    • changedInput schema / properties / page_token / description
      Previous value: -"Token for keyset pagination. Use the next_page_token value returned in the previous response to retrieve the next page."New value: +"Keyset token from the previous next_page_token"
    • changedInput schema / properties / pagination / description
      Previous value: -"Pagination method. Use 'keyset' for keyset-based pagination (required for repositories with many files). Non-keyset calls keep the legacy array response for backward compatibility; that legacy response shape is deprecated and may be removed in a future major release. Keyset calls return a structured response with items and next_page_token when more pages are available."New value: +"Use keyset for large trees (items + next_page_token). Omit both page and pagination for the legacy array (deprecated)."
    • changedInput schema / properties / path / description
      Previous value: -"The path inside the repository"New value: +"Path inside the repository"
    • changedInput schema / properties / per_page / description
      Previous value: -"Number of results to show per page"New value: +"Items per page"
    • changedInput schema / properties / project_id / description
      Previous value: -"The ID or URL-encoded path of the project"New value: +"Project ID or URL-encoded path"
    • changedInput schema / properties / recursive / description
      Previous value: -"Boolean value to get a recursive tree"New value: +"Recursive tree"
    • changedInput schema / properties / ref / description
      Previous value: -"The name of a repository branch or tag. Defaults to the default branch."New value: +"Branch or tag. Defaults to the default branch."
  2. Changed1 schema field changedv2.1.66
    • addedInput schema / properties / jmespath
      Added value: +{
+  "description": "Optional JMESPath expression filtering the JSON result before return.",
+  "type": "string"
+}
  3. Addedv2.1.45
  4. Removedv2.1.43
  5. Addedv2.1.18
  6. Removedv2.1.14
  7. Addedv2.1.11
  8. Removedv2.1.10
  9. Changed4 schema fields changedv2.1.9
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / page_token / description
      Previous value: -"The tree record ID for pagination"New value: +"Token for keyset pagination. Use the next_page_token value returned in the previous response to retrieve the next page."
    • changedInput schema / properties / pagination / description
      Previous value: -"Pagination method (keyset)"New value: +"Pagination method. Use 'keyset' for keyset-based pagination (required for repositories with many files). Non-keyset calls keep the legacy array response for backward compatibility; that legacy response shape is deprecated and may be removed in a future major release. Keyset calls return a structured response with items and next_page_token when more pages are available."
    • addedInput schema / required
      Added value: +[
+  "project_id"
+]
  10. First observedv1.0.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. Beyond that the description discloses nothing about the behavior that actually matters here: three mutually exclusive pagination modes including a deprecated legacy array, item + next_page_token response shapes, and how recursive affects result size. For a nine-parameter listing tool this is a substantial behavioral gap.

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?

A single front-loaded sentence with zero filler, and the core purpose lands immediately. It is clean, though its brevity is achieved by omission rather than by tight editing of richer content.

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?

With nine parameters, no output schema, and a pagination design that includes a deprecated default mode, one sentence is not enough for an agent to call this correctly on large trees. The description should at minimum point at recursive/path scoping and warn against omitting both page and pagination.

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%, so every one of the nine parameters is already documented, which sets the baseline at 3. The description adds no meaning on top — it says nothing about what recursive returns, what path scoping does, or the three-way pagination choice (keyset, page, deprecated legacy array).

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?

"List files and directories in a repository" gives a specific verb and resource, and it implicitly reads as a tree/listing operation distinct from get_file_contents. However, it never names get_file_contents or get_repository_tree's own scope boundary (e.g. single-file retrieval vs. directory traversal), so sibling differentiation is left to inference.

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 on when to prefer this over get_file_contents, get_branch, or search_repositories. Nothing tells the agent to set recursive for deep traversal, to use path to scope a subtree, or which pagination mode to pick — all decisions the caller must guess at.

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

Deploy Server

Other Tools