Skip to main content
Glama
PaSympa

discord-mcp

by PaSympa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

discord_edit_role

Idempotent

Update a Discord role's name, color, permissions, hoist, or mentionable setting. Only specified fields change; supplying permissions replaces the full permission set.

Instructions

Update an existing role's name, color, permissions, hoist, or mentionable flag. Only provided fields change; passing permissions REPLACES the role's full permission set. Requires the Manage Roles permission, and the role must be below the bot's highest role.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoNew role name (max 100 characters).
colorNoNew role color as a hex string, e.g. '#FF5733'.
hoistNoIf true, display members with this role separately in the member list.
role_idYesID (snowflake) of the role to edit.
guild_idYesDiscord server (guild) ID (snowflake).
mentionableNoIf true, anyone can @mention this role.
permissionsNoPermission flag names. Providing this REPLACES the role's entire permission set. Uses Discord PermissionsBitField flag names.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.2.0
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed6 schema fields changedv2.0.0
    • addedInput schema / properties / color / pattern
      Added value: +"^#[0-9A-Fa-f]{6}$"
    • addedInput schema / properties / guild_id / pattern
      Added value: +"^\\d{17,20}$"
    • addedInput schema / properties / permissions / anyOf
      Added value: +[
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "string"
+  }
+]
    • removedInput schema / properties / permissions / items
      Removed value: -{
-  "type": "string"
-}
    • removedInput schema / properties / permissions / type
      Removed value: -"array"
    • addedInput schema / properties / role_id / pattern
      Added value: +"^\\d{17,20}$"
  3. Changed7 schema fields changedv1.6.0
    • addedInput schema / properties / color / description
      Added value: +"New role color as a hex string, e.g. '#FF5733'."
    • addedInput schema / properties / guild_id / description
      Added value: +"Discord server (guild) ID (snowflake)."
    • addedInput schema / properties / hoist / description
      Added value: +"If true, display members with this role separately in the member list."
    • addedInput schema / properties / mentionable / description
      Added value: +"If true, anyone can @mention this role."
    • addedInput schema / properties / name / description
      Added value: +"New role name (max 100 characters)."
    • addedInput schema / properties / permissions / description
      Added value: +"Permission flag names. Providing this REPLACES the role's entire permission set. Uses Discord PermissionsBitField flag names."
    • addedInput schema / properties / role_id / description
      Added value: +"ID (snowflake) of the role to edit."
  4. Addedv1.5.0
  5. Removedv1.0.0
  6. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses critical behavior: partial updates are the default, but passing 'permissions' replaces the entire permission set. It also reveals authorization and hierarchy constraints. This is exactly the kind of behavioral context an agent needs to avoid unintended permission overwrites.

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?

Three dense sentences with no filler. The first sentence states the tool's purpose and scope, the second explains the critical partial-update and replacement semantics, and the third covers permissions and hierarchy. Information is front-loaded and every sentence earns its place.

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?

Given a 7-parameter mutation tool with no output schema, the description is complete enough for correct selection and invocation. It covers what changes, how partial updates work, the dangerous permissions-replacement behavior, and the required permission/position conditions. No critical gap remains.

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?

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying the update contract: unspecified fields remain unchanged and permissions are replaced wholesale rather than merged. This is valuable semantic information not fully captured by the field descriptions alone.

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?

Description uses a specific verb ('Update') and resource ('existing role'), and enumerates the exact mutable attributes: name, color, permissions, hoist, mentionable. This clearly differentiates it from sibling tools like discord_create_role, discord_delete_role, discord_set_role_position, and discord_set_role_permission.

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

Usage Guidelines4/5

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

The description gives clear operational context: it edits role settings, only provided fields change, and it states important prerequisites (Manage Roles permission and role position below the bot's highest role). It does not explicitly name alternatives or state when not to use this tool, but the scope is unambiguous.

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