Skip to main content
Glama

list_commits

Retrieve commit history for GitLab projects to track changes, filter by branch, tag, or file path, and manage repository revisions.

Instructions

列出 Commits

Args: project_id: 專案 ID 或路徑 ref_name: 分支或標籤名稱(預設為預設分支) path: 檔案路徑篩選 page: 頁碼 per_page: 每頁筆數

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYes
ref_nameNo
pathNo
pageNo
per_pageNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • Tool handler for listing commits, registered with @mcp.tool().
    @mcp.tool()
    def list_commits(project_id: int | str, ref_name: str = None,
                     path: str = None, page: int = 1, per_page: int = 20) -> str:
        """列出 Commits
    
        Args:
            project_id: 專案 ID 或路徑
            ref_name: 分支或標籤名稱(預設為預設分支)
            path: 檔案路徑篩選
            page: 頁碼
            per_page: 每頁筆數
        """
        try:
            client = get_client()
            commits = client.list_commits(project_id, ref_name=ref_name, path=path,
                                           page=page, per_page=per_page)
            if not commits:
                return "找不到符合條件的 commits"
    
            lines = [f"找到 {len(commits)} 個 commits:\n"]
            for c in commits:
                lines.append(
                    f"- {c.get('short_id', 'N/A')} {c.get('title', 'N/A')}"
                    f"\n  作者: {c.get('author_name', 'N/A')} | {c.get('authored_date', 'N/A')}"
                )
            return "\n".join(lines)
        except GitLabAPIError as e:
            return f"列出 commits 失敗: {str(e)}"
  • Actual implementation of the commit listing logic in the GitLab client.
    def list_commits(
        self,
        project_id: int | str,
        ref_name: str = None,
        path: str = None,
        page: int = 1,
        per_page: int = 20,
    ) -> list[dict]:
        """GET /projects/:id/repository/commits"""
        pid = self._resolve_project_id(project_id)
        params = {"page": page, "per_page": per_page}
        if ref_name:
            params["ref_name"] = ref_name
        if path:
            params["path"] = path
        return self._get_json(f"/projects/{pid}/repository/commits", params=params)
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions pagination parameters (page, per_page) which hints at paginated results, but doesn't disclose other behavioral traits like authentication requirements, rate limits, error conditions, or what happens when parameters are invalid. The description is minimal beyond parameter listing.

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 appropriately sized with a clear header and parameter list. It's front-loaded with the purpose, though the parameter explanations are brief. No redundant sentences, but could be more structured with usage examples or constraints.

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?

Given 5 parameters with 0% schema coverage and no annotations, the description is incomplete—it lacks behavioral details, error handling, and usage context. However, an output schema exists (not shown here), which may cover return values, reducing the burden on the description. The description provides basic parameter semantics but misses broader context.

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 0%, so the description must compensate. It provides brief Chinese explanations for each parameter (e.g., '專案 ID 或路徑' for project_id, '分支或標籤名稱' for ref_name), adding some semantic context beyond the schema's titles. However, it doesn't explain parameter interactions, constraints, or provide examples, leaving significant gaps.

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

Purpose3/5

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

The description states '列出 Commits' (List Commits) which clearly indicates the verb and resource, but it's vague about scope and doesn't differentiate from sibling tools like 'get_commit' or 'list_repository_tree'. It doesn't specify whether this lists all commits in a repository or commits for specific criteria.

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 use this tool versus alternatives like 'get_commit' (for single commit details) or 'list_repository_tree' (for file listings). The description only lists parameters without context about appropriate use cases or prerequisites.

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

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