Skip to main content
Glama

Custom Emoji

gitlab_custom_emoji
Destructive

Manage group-level custom emoji: list existing, create new ones with a name and image URL, or delete them from your group's selection.

Instructions

Use {"action":"create","params":{...}}; only top-level keys are action and params. Action params schema: gitlab://schema/meta/gitlab_custom_emoji/.

Manage group-level custom emoji via GraphQL. Delete is destructive: existing reactions using the emoji remain in the database but render as :name: text. The underlying GitLab API requires a Premium/Ultimate plan on the target instance (server enforces it with 403); the tool itself is always registered and is not gated by GITLAB_ENTERPRISE. When to use: list, add, or remove the custom emoji available to a group's projects (e.g. company logos, team mascots) used as reactions on issues/MRs/notes. NOT for: posting or removing a reaction on an issue/MR/snippet/commit/note (use the emoji_issue_* / emoji_mr_* / emoji_snippet_* actions on gitlab_issue, gitlab_merge_request, or gitlab_snippet), Unicode emoji (built-in, no action required), instance-level emoji (not supported by GitLab).

Returns:

  • list: {nodes: [{id, name, url, external (bool), created_at, user_permissions: {delete}}], page_info: {end_cursor, has_next_page}}.

  • create: the created node {id, name, url, external, created_at}.

  • delete: {success: bool, message: string}. Errors: 404 not found (hint: check group_path or id GID), 403 forbidden (hint: requires Maintainer+ on the group and Premium/Ultimate), 400 invalid params (hint: name must not contain colons; url must be a publicly reachable image).

Param conventions: * = required. id format = GID (gid://gitlab/CustomEmoji/123). group_path = full namespace path (e.g. mygroup or mygroup/subgroup).

  • list: group_path*, first (max 100), after (cursor)

  • create: group_path*, name* (no colons), url* (HTTPS image URL)

  • delete: id*

See also: gitlab_group (group settings and membership), gitlab_issue / gitlab_merge_request / gitlab_snippet (post reactions using the emoji).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform. Pick exactly one of the values in `enum`. Each action expects its own `params` object — see the tool description for the per-action parameter list.
paramsNoAction-specific parameters as a JSON object. Required and optional fields differ per action. This envelope schema stays broad; runtime validation applies the chosen action's schema after reserved meta keys like `confirm` are stripped. For the JSON Schema of a specific action's `params`, read the MCP resource `gitlab://schema/meta/{tool}/{action}` (replace placeholders with the tool name and the chosen action).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
next_stepsNoOptional. Suggested follow-up actions or tool calls for the LLM, contextual to the result.
paginationNoPresent on list actions. Use `has_more` and `next_page` to paginate through results.
Behavior5/5

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

Annotations include destructiveHint=true; description adds that delete leaves existing reactions (rendered as :name: text), requires Premium/Ultimate plan, tool always registered—clarifying behavioral traits beyond annotations. No contradiction.

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

Conciseness5/5

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

Well-structured, front-loaded with key info (action pattern, behavior, usage, returns, errors, params, see also). Each sentence adds value; no waste given complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all: action list, return formats per action, error hints (404, 403, 400), parameter conventions, auth requirements. Output schema exists and description mentions return fields. Complete for a multifaceted tool.

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

Parameters5/5

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

Schema has 100% coverage, but description adds per-action parameter details (list: group_path*, first, after; create: group_path*, name*, url*; delete: id*) with conventions (GID format, no colons). Adds meaning beyond schema.

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

Purpose5/5

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

The description clearly states the tool manages group-level custom emoji via GraphQL, listing actions (list, create, delete) and distinguishing it from posting reactions (use other tools). It specifies verb+resource and differentiates from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (list, add, remove custom emoji for a group's projects) and when NOT to use (posting reactions, Unicode emoji, instance-level emoji). Provides 'See also' with alternative tools.

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

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