gitlab-api

Get user

gitlab_get_user

Read-onlyIdempotent

Retrieve details for a specific GitLab user by ID or username. Use it to look up profile and account information through the GitLab API.

Instructions

Get information about a specific user.

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

Returns: Response: A wrapper containing the original response and a User model.

Raises: MissingParameterError: If the user_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_user"
  }
}

Input Schema

Name	Required	Description	Default
`data`	No
`name`	No
`page`	No
`sort`	No
`sudo`	No
`admin`	No
`email`	No
`active`	No
`admins`	No
`humans`	No
`blocked`	No
`user_id`	No
`external`	No
`order_by`	No
`password`	No
`per_page`	No
`provider`	No
`username`	No
`max_pages`	No
`extern_uid`	No
`two_factor`	No
`total_pages`	No
`created_after`	No
`created_before`	No
`exclude_external`	No
`exclude_internal`	No
`saml_provider_id`	No
`without_projects`	No
`skips_confirmation`	No
`without_project_bots`	No
`with_custom_attributes`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv27.3.20Nov 7, 2026

removedInput schema / properties / api_parameters

Removed value: -{
-  "anyOf": [
-    {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null
-}

changedInput schema / properties / sudo / default
```
Previous value: -falseNew value: +null
```

First observedv27.3.13Oct 25, 2026

TDQS

C2.8/5.0

Behavior3/5

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine value by disclosing the return wrapper (a User model) and error behavior (MissingParameterError on missing user_id, ParameterError on invalid input). However, it claims user_id is required while the schema lists zero required parameters and 31 mostly filter-style options, creating confusion about the actual call contract.

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 a Python docstring pasted verbatim, including an "Args: **kwargs" entry that conveys no information and a Raises block whose ordering buries the essential user_id requirement. Useful content (the return shape and the missing-parameter error) is not front-loaded; the first line is the only agent-facing summary.

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?

The description does explain the response wrapper even though no output schema exists, which is a plus. But for a 31-parameter tool with zero schema documentation, it is far too thin: an agent cannot tell which of the many optional fields matter for a single-user fetch, nor whether the tool may return a list when user_id is omitted.

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 31 parameters, so the description carries the full explanatory burden and does not meet it. It mentions only user_id, and does so dismissively via "**kwargs ... (e.g., user_id)", leaving page, per_page, sort, order_by, admin, active, blocked, created_after and the rest completely undefined despite their apparent list-filter semantics.

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 names a specific verb and resource ("Get information about a specific user"), which is clearly distinct from mutating siblings like gitlab_update_user or gitlab_delete_user. It does not, however, distinguish itself from the closely related gitlab_get_users listing tool, leaving ambiguity about single-lookup versus list behavior.

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 statement of when to use this tool versus gitlab_get_users, gitlab_get_project_members, or gitlab_get_group_members, all of which surface user data in the sibling list. The only implied guidance is that it targets one user, which the agent must infer from the phrase "a specific user".

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server