Skip to main content
Glama

Get project groups

gitlab_get_project_groups
Read-onlyIdempotent

Get the GitLab groups linked to a specific project by supplying its project ID, so you can see which groups the project belongs to.

Instructions

Get groups associated with a specific project.

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

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

Raises: MissingParameterError: If the project_id 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_get_project_groups"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNo
keyNo
refNo
cronNo
dataNo
nameNo
pageNo
pathNo
sortNo
tierNo
forceNo
limitNo
ownedNo
topicNo
valueNo
activeNo
avatarNo
beforeNo
mirrorNo
searchNo
simpleNo
statesNo
topicsNo
dry_runNo
starredNo
archivedNo
group_idNo
id_afterNo
importedNo
order_byNo
per_pageNo
tag_listNo
tag_nameNo
topic_idNo
id_beforeNo
max_pagesNo
expires_atNo
import_urlNo
membershipNo
project_idNo
statisticsNo
visibilityNo
descriptionNo
lfs_enabledNo
total_pagesNo
external_urlNo
group_accessNo
merge_methodNo
build_timeoutNo
cron_timezoneNo
public_buildsNo
squash_optionNo
variable_typeNo
approval_rulesNo
ci_config_pathNo
default_branchNo
environment_idNo
include_hiddenNo
mirror_user_idNo
emails_disabledNo
issues_templateNo
cluster_agent_idNo
environment_nameNo
min_access_levelNo
packages_enabledNo
allowed_to_createNo
auto_stop_settingNo
search_namespacesNo
wiki_access_levelNo
build_git_strategyNo
flux_resource_pathNo
pages_access_levelNo
repository_storageNo
auto_devops_enabledNo
builds_access_levelNo
ci_separated_cachesNo
create_access_levelNo
issues_access_levelNo
ci_default_git_depthNo
deploy_access_levelsNo
forking_access_levelNo
keep_latest_artifactNo
kubernetes_namespaceNo
merge_trains_enabledNo
pipeline_schedule_idNo
service_desk_enabledNo
merge_commit_templateNo
mirror_trigger_buildsNo
releases_access_levelNo
snippets_access_levelNo
analytics_access_levelNo
approvals_before_mergeNo
include_pending_deleteNo
mr_default_target_selfNo
request_access_enabledNo
shared_runners_enabledNo
squash_commit_templateNo
merge_pipelines_enabledNo
merge_requests_templateNo
operations_access_levelNo
repository_access_levelNo
requirements_access_levelNo
suggestion_commit_messageNo
repository_checksum_failedNo
auto_devops_deploy_strategyNo
autoclose_referenced_issuesNo
merge_requests_access_levelNo
auto_cancel_pending_pipelinesNo
ci_forward_deployment_enabledNo
enforce_auth_checks_on_uploadsNo
only_mirror_protected_branchesNo
allow_merge_on_skipped_pipelineNo
container_registry_access_levelNo
restrict_user_defined_variablesNo
remove_source_branch_after_mergeNo
resolve_outdated_diff_discussionsNo
mirror_overwrites_diverged_branchesNo
printing_merge_request_link_enabledNo
security_and_compliance_access_levelNo
only_allow_merge_if_pipeline_succeedsNo
container_expiration_policy_attributesNo
external_authorization_classification_labelNo
only_allow_merge_if_all_status_checks_passedNo
ci_allow_fork_pipelines_to_run_in_parent_projectNo
only_allow_merge_if_all_discussions_are_resolvedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv27.3.20
    • changedInput schema / properties / active / default
      Previous value: -trueNew value: +null
    • removedInput schema / properties / api_parameters
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "additionalProperties": true,
      -      "type": "object"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null
      -}
    • removedInput schema / properties / import_url / anyOf
      Removed value: -[
      -  {
      -    "format": "uri",
      -    "maxLength": 2083,
      -    "minLength": 1,
      -    "type": "string"
      -  },
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / import_url / title
      Added value: +"Import Url"
  2. First observedv27.3.13

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds some value by naming the return wrapper and Group models and by documenting error behavior. However, it claims project_id is required while the schema declares zero required parameters, and it says nothing about pagination or filtering across the large parameter set.

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 short and the key purpose is front-loaded in the first sentence. The Args/Returns/Raises structure is readable, though some lines are boilerplate and the kwargs phrasing does not match the explicit schema.

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 with 125 parameters, no output schema, and no parameter descriptions, the definition is far too thin. It does not explain pagination, filtering behavior, or which parameters actually apply to this operation, and its project_id requirement conflicts with the schema.

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?

The schema has 125 parameters with 0% description coverage, so the description carries the full burden of explaining parameter meaning. It mentions only project_id as an example and otherwise says 'Additional parameters,' leaving the other 124 parameters completely unexplained.

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 clear verb and resource: 'Get groups associated with a specific project.' An agent can understand the basic operation. However, it does not distinguish this from sibling tools such as gitlab_get_group_projects or gitlab_get_groups, so the selection boundary is left implicit.

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, no prerequisites, and no exclusions. The only hint is that project_id is an example parameter in kwargs, which is not enough to guide tool selection.

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