Skip to main content
Glama

Get commit comments

gitlab_get_commit_comments
Read-onlyIdempotent

Fetch comments on a GitLab commit to inspect review feedback and discussion attached to a specific commit.

Instructions

Get comments on a commit.

Args: **kwargs: Additional parameters for the request.

Returns: Response: A wrapper containing the original response and a list of Comment models.

Raises: 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_commit_comments"
  }
}

Input Schema

NameRequiredDescriptionDefault
allNo
refNo
dataNo
lineNo
nameNo
noteNo
pageNo
pathNo
forceNo
sinceNo
stateNo
statsNo
untilNo
branchNo
actionsNo
contextNo
dry_runNo
messageNo
coverageNo
per_pageNo
ref_nameNo
user_idsNo
group_idsNo
line_typeNo
max_pagesNo
rule_typeNo
start_shaNo
project_idNo
target_urlNo
with_statsNo
author_nameNo
commit_hashNo
descriptionNo
pipeline_idNo
report_typeNo
author_emailNo
start_branchNo
start_projectNo
protected_branch_idsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv27.3.20
    • removedInput schema / properties / api_parameters
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "additionalProperties": true,
      -      "type": "object"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null
      -}
    • removedInput schema / properties / author_email / anyOf
      Removed value: -[
      -  {
      -    "format": "email",
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / author_email / title
      Added value: +"Author Email"
    • changedInput schema / properties / page / default
      Previous value: -1New value: +null
    • changedInput schema / properties / per_page / default
      Previous value: -100New value: +null
    • addedInput schema / properties / project_id / default
      Added value: +null
    • removedInput schema / properties / target_url / anyOf
      Removed value: -[
      -  {
      -    "format": "uri",
      -    "maxLength": 2083,
      -    "minLength": 1,
      -    "type": "string"
      -  },
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / target_url / title
      Added value: +"Target Url"
    • removedInput schema / required
      Removed value: -[
      -  "project_id"
      -]
  2. First observedv27.3.13

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only that it returns a wrapper with Comment models and raises ParameterError on invalid input, which is minimal beyond structured data and omits pagination and filtering behavior for a 39-parameter tool.

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

Conciseness2/5

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

The text is short but consists largely of boilerplate docstring scaffolding (Args/Returns/Raises) with a meaningless **kwargs placeholder. It is under-specified rather than concise, and the only substantive sentence is the first one.

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 tool exposing 39 loosely typed parameters with no output schema and no annotations about scope, the description is far too thin. It gives a return-type hint (Comment models) but leaves the agent unable to know which parameters matter or how results are shaped.

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

Parameters1/5

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

Schema description coverage is 0% across 39 parameters, and the description dismisses them all as '**kwargs: Additional parameters for the request.' No parameter is named, explained, or mapped to the commit-comment domain, leaving the entire parameter surface undocumented.

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 line states a specific verb and resource: 'Get comments on a commit,' which is clear and actionable. However, it does not differentiate from nearby siblings like gitlab_get_commit_discussions or gitlab_get_notes, which an agent could easily confuse with this tool.

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 guidance on when to use this tool versus alternatives such as gitlab_get_commit_discussions, gitlab_get_notes, or gitlab_create_commit_comment. The agent must infer usage entirely from the name.

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