Skip to main content
Glama
Discord MCP - Discord server management MCP for AI agents

Discord MCP - Discord server management MCP for AI agents

Update role

update_role

Edit a Discord role's name, color, icon, hoist, mentionable flag, or permissions; only passed fields change, and sensitive permission updates require confirmation.

Instructions

Edit a role's name, color (solid, gradient, or holographic), icon, hoist, mentionable flag, or permissions. Passing preset and/or permissions replaces the role's permission set with the named bundle plus listed names. Only passed fields change. Supports dry_run. A permission change that would give the role moderator or admin powers (such as banning, kicking, or timing out members, deleting other people's messages, or managing the server, roles, or channels), or let it see channels it cannot see now, needs confirming: the first call changes nothing and returns a preview and a confirm_token, and repeating the call with the token makes the change.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "role": "<role>"
    },
    "name": "update_role"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNo
roleYesRole name or ID.
colorNoHex color like #00b0f4.
guildNoGuild (server) name or ID. Omit to use the default guild.
hoistNo
presetNo
dry_runNo
icon_urlNoPublic URL of a small image (png, jpeg, webp; 256 KB) shown beside members' names, or none to remove. Needs boost level 2.
icon_emojiNoA standard emoji shown beside members' names instead of an image, or none to remove. Needs boost level 2.
holographicNoDiscord's holographic style, which uses its own three colors; false for a solid color. Needs the Enhanced Role Colors server feature.
mentionableNo
permissionsNo
confirm_tokenNoThe token from this exact action's preview. Where the app can show a confirmation dialog, calling with it asks the user there, and it happens only if they agree.
secondary_colorNoA second hex color, so the role name shows a gradient from color to this one; none for a solid color. Needs the Enhanced Role Colors server feature.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.4.2
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / properties / confirm_token
      Added value: +{
      +  "description": "The token from this exact action's preview. Where the app can show a confirmation dialog, calling with it asks the user there, and it happens only if they agree.",
      +  "type": "string"
      +}
    • addedInput schema / properties / holographic
      Added value: +{
      +  "description": "Discord's holographic style, which uses its own three colors; false for a solid color. Needs the Enhanced Role Colors server feature.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / icon_emoji
      Added value: +{
      +  "description": "A standard emoji shown beside members' names instead of an image, or none to remove. Needs boost level 2.",
      +  "type": "string"
      +}
    • addedInput schema / properties / icon_url
      Added value: +{
      +  "description": "Public URL of a small image (png, jpeg, webp; 256 KB) shown beside members' names, or none to remove. Needs boost level 2.",
      +  "type": "string"
      +}
    • addedInput schema / properties / secondary_color
      Added value: +{
      +  "description": "A second hex color, so the role name shows a gradient from color to this one; none for a solid color. Needs the Enhanced Role Colors server feature.",
      +  "type": "string"
      +}
  2. Changed1 schema field changedv1.3.0
    • removedInput schema / additionalProperties
      Removed value: -false
  3. First observedv1.0.2

TDQS

A3.8/5.0
Behavior4/5

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

Goes well beyond the readOnlyHint=false/destructiveHint=false annotations by disclosing replace-vs-merge semantics ('Passing preset and/or permissions replaces the role's permission set'), 'Only passed fields change', dry_run support, and the two-step confirm_token preview flow for privilege escalation. The escalation trigger list (banning, deleting messages, managing roles/channels, exposing new channels) is genuinely useful pre-call context. Minor gap: it does not say whether the preview is returned in the same shape as the final result.

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?

Front-loads the editable fields, then the replacement semantics, then the confirmation flow in a logical order with no filler. The final sentence is long and dense but each clause carries distinct behavior an agent needs.

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

Completeness4/5

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

For a 14-parameter mutation tool with no output schema, the description covers the risky parts: partial-update semantics, irreversible-looking permission replacement, dry_run, and the preview/confirm escalation gate. Remaining gaps (guild defaulting, what the preview contains, format of permission names) are moderate but not call-breaking.

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

Parameters4/5

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

At 57% schema coverage, several parameters (name, hoist, mentionable, permissions items, preset) have no schema description, and the description compensates for the most consequential one by explaining that preset and permissions together replace the permission set rather than add to it. It also clarifies color modes (solid, gradient via secondary_color, holographic) and that only passed fields change. It still says nothing about the shape of the permissions array entries, which the schema leaves as bare strings.

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?

Opens with a specific verb and resource plus the exact editable fields ('Edit a role's name, color..., icon, hoist, mentionable flag, or permissions'), which is far more than a restatement of the title. It does not explicitly name create_role/delete_role/bulk_update_roles as the alternatives, so sibling differentiation 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 Guidelines3/5

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

The description explains how to use the tool once chosen (partial update semantics, preset vs permissions, dry_run, confirm flow) but never states when to pick it over update_role-adjacent siblings such as bulk_update_roles or clone_role. Usage is implied by the field list rather than routed.

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