Skip to main content
Glama

Get project contributors

gitlab_get_project_contributors
Read-onlyIdempotent

Retrieve contributors for a GitLab project by project ID, returning user details so you can identify and analyze project participation.

Instructions

Get information about contributors to a project.

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

Returns: Response: A wrapper containing the original response and a list of User 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_contributors"
  }
}

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.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered by structured data. The description adds genuine value by disclosing the return shape (a response wrapper containing a list of User models) and the two error types thrown. It omits pagination and ordering behavior despite the schema exposing page/per_page/max_pages/order_by.

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

Conciseness3/5

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

The purpose sentence is front-loaded and the docstring is short, but the Args section is near-useless boilerplate and arguably misleading for a 125-parameter schema. The Returns and Raises lines do earn their place.

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, zero schema descriptions, and no output schema, the description covers only project_id and the response wrapper. An agent has no basis for choosing pagination values, understanding ordering semantics, or knowing which of the many unrelated-looking parameters (e.g., mirror, dry_run, visibility) are actually valid for this endpoint.

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?

Schema description coverage is 0% across 125 parameters, so the description carries the full burden and largely fails it. The single Args line dismisses everything as "**kwargs: Additional parameters for the request (e.g., project_id)", which leaves 124 parameters including sort, page, per_page, and max_pages entirely undefined and even implies the signature is a loose passthrough.

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?

"Get information about contributors to a project" is a specific verb plus resource and is immediately understandable. However, it does nothing to distinguish itself from near-twin siblings such as gitlab_get_project_members or gitlab_get_users, so an agent must infer the difference from the names alone.

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 when-to-use guidance, no mention of prerequisites (token scopes, access level needed to see contributors), and no alternatives named. The only conditional statement is a Raises clause about a missing project_id, which is error behavior rather than usage guidance.

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