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

Discord MCP - Discord server management MCP for AI agents

by OrygnsCode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Update bot profile

update_bot_profile

Edit a Discord bot's server nickname, avatar, banner, and bio, or its global username, avatar, and banner. Use server scope for community-specific looks; use everywhere scope for all servers.

Instructions

Change how the bot looks. In one server (the default): its nickname, avatar, banner, and bio there, shown only in that server, so one bot can look different in each community. Everywhere (scope everywhere): its username, avatar, and banner, for every server it is in. Images come from public URLs; none removes a server-only one, so the global one shows again. A replaced avatar or banner is saved to the data folder first, since Discord does not keep it. Discord limits username changes to about two an hour.

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": "update_bot_profile"
  }
}

Input Schema

NameRequiredDescriptionDefault
bioNoServer only: the About Me shown in that server, or none. The bot's own About Me is set in the Developer Portal.
botNoWhich bot to act as, by name, when more than one is configured. Omit to use the default bot, or with a server, the bot that handles it.
guildNoGuild (server) name or ID. Omit to use the default guild.
scopeNoserver (default) changes it in one server only; everywhere changes the bot's own profile.
dry_runNo
nicknameNoServer only: the name shown in that server, or none to show the username.
usernameNoEverywhere only: the bot's username.
avatar_urlNoPublic URL of the avatar image (png, jpeg, gif, webp), or none.
banner_urlNoPublic URL of the profile banner image, or none.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.2

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write/non-destructive profile is covered. The description still adds real behavioral context beyond them: replaced avatars/banners are backed up to the data folder because Discord discards them, "none" clears a server override, and username changes are rate-limited to roughly two per hour. That is strong added value, though the return behavior and what dry_run does are unstated.

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?

Dense but well front-loaded: it leads with the action, then the two scope modes, then image handling, backup behavior, and the rate limit. The parenthetical glosses ("(the default)", "(scope everywhere)") are slightly repetitive but each sentence still carries information.

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 9-parameter mutation tool with no output schema and no required parameters, this covers the hard parts: scope semantics, the "none" sentinel, image backup, and rate limits. Gaps remain around dry_run and around precedence when guild and scope=everywhere are combined, which an agent would have to guess.

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 89%, so the baseline is 3, but the description goes beyond the schema by explaining that images must be public URLs, that passing "none" removes a server-only value and re-exposes the global one, and which fields are scope-restricted. The only uncovered parameter, dry_run, has no description in either place.

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?

States a specific verb and resource ("Change how the bot looks") and immediately splits it into two distinct scopes with the exact fields affected in each. Between the field-level detail and the scope split, an agent can tell this apart from get_bot_info or set_bot_presence without opening the schema.

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?

Gives clear selection guidance: per-server changes are the default and cover nickname/avatar/banner/bio, while "everywhere" covers username/avatar/banner globally. It does not mention when to prefer other tools (e.g. set_bot_presence for status) or that all parameters are optional, so it stops just short of full when/when-not 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