Skip to main content
Glama

gitlab_list_branches

List all branches in a GitLab repository with latest commit information. Use to check available branches, find feature branches, or filter results by search criteria.

Instructions

List repository branches Returns: All branches with latest commit info Use when: Checking branches, finding feature branches Optional: Search filter

Example response: [{ "name": "main", "protected": true, "merged": false, "can_push": true, "default": true, "commit": { "id": "abc123...", "short_id": "abc123", "title": "Latest commit" } }]

Related tools:

  • gitlab_create_branch: Create new branch

  • gitlab_delete_branch: Remove branch

  • gitlab_compare_refs: Compare branches

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idNoProject ID or path (optional - auto-detects from git)

Implementation Reference

  • Handler function that implements the gitlab_list_branches tool by resolving the project ID (auto-detecting from git if not provided) and calling GitLabClient.get_branches() to retrieve the list of branches.
    def handle_list_branches(client: GitLabClient, arguments: Optional[Dict[str, Any]]) -> Any:
        """Handle listing branches"""
        project_id = require_project_id(client, arguments)
        return client.get_branches(project_id)
  • MCP tool registration in server.list_tools() including name, description from tool_descriptions, and input schema allowing optional project_id.
    types.Tool(
        name=TOOL_LIST_BRANCHES,
        description=desc.DESC_LIST_BRANCHES,
        inputSchema={
            "type": "object",
            "properties": {
                "project_id": {"type": "string", "description": "Project ID or path (optional - auto-detects from git)"}
            }
        }
    ),
  • Tool schema definition in tool_definitions.py (duplicate/alternative to server.py) defining input schema for project_id.
    types.Tool(
        name=TOOL_LIST_BRANCHES,
        description=desc.DESC_LIST_BRANCHES,
        inputSchema={
            "type": "object",
            "properties": {
                "project_id": {"type": "string", "description": "Project ID or path (optional - auto-detects from git)"}
            }
        }
  • Registration of the handler function in the TOOL_HANDLERS dictionary used by server.call_tool() for dispatching.
    TOOL_LIST_BRANCHES: handle_list_branches,
  • Constant defining the tool name string used throughout the codebase.
    TOOL_LIST_BRANCHES = "gitlab_list_branches"
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the return format ('All branches with latest commit info') and provides an example response, which is helpful. However, it doesn't mention important behavioral aspects like whether this is a paginated endpoint, rate limits, authentication requirements, or error conditions.

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 description is well-structured with clear sections (purpose, returns, usage, optional feature, example, related tools). While the example response is detailed, it serves a useful purpose in clarifying the output format. The related tools section is helpful but could be more concise by focusing only on the most relevant siblings.

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?

For a tool with no annotations and no output schema, the description provides reasonable coverage of purpose and usage. The example response partially compensates for the lack of output schema. However, important contextual information about authentication, pagination, error handling, and the relationship to other list tools in the extensive sibling set is missing.

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% with one parameter documented in the schema. The description mentions 'Optional: Search filter' which doesn't directly correspond to the 'project_id' parameter in the schema, creating some confusion. It adds minimal value beyond what the schema already provides about the single parameter.

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 verb ('List') and resource ('repository branches'), making the purpose immediately understandable. It distinguishes from some siblings like 'gitlab_create_branch' and 'gitlab_delete_branch' by indicating a read operation, though it doesn't explicitly differentiate from other list tools like 'gitlab_list_tags' or 'gitlab_list_commits' in the same repository context.

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

Usage Guidelines4/5

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

The 'Use when' section provides clear context ('Checking branches, finding feature branches'), which helps the agent understand appropriate scenarios. It mentions an optional search filter, though it doesn't explicitly state when NOT to use this tool or name specific alternatives among the many sibling tools.

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/Vijay-Duke/mcp-gitlab'

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