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

Create webhook

create_webhook

Create an incoming webhook on a Discord channel to post messages under a custom display name and avatar for announcements or role-based messaging.

Instructions

Create an incoming webhook on a channel. Webhooks post with any display name and avatar, which is how messages 'as someone' work legitimately.

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": {
      "channel": "<channel>",
      "name": "<name>"
    },
    "name": "create_webhook"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
guildNoGuild (server) name or ID. Omit to use the default guild.
channelYesChannel name or ID.
avatar_urlNoImage for the webhook's default avatar, up to 1 MB.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field 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"
  2. Changed1 schema field changedv1.3.0
    • removedInput schema / additionalProperties
      Removed value: -false
  3. First observedv1.0.2

TDQS

B3.2/5.0
Behavior3/5

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

The annotations already say readOnlyHint=false and destructiveHint=false, so the description does not need to restate that this is a mutation. It does add real context about impersonation semantics ('post with any display name and avatar'), which explains why this exists alongside plain message sending. It omits important operational details for a credential-creating tool, though: that the call yields a webhook URL/token to store, and what permissions are required.

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?

Two sentences, front-loaded with the action, no filler or hedging. The second sentence is informative rather than redundant, though its 'legitimately' phrasing is a policy aside that could be trimmed without losing tool-selection value.

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?

With no output schema, the description is the only place an agent could learn what comes back, and it says nothing about the resulting webhook URL/token that must be captured. For a four-parameter mutation tool that mints a persistent credential, that is a meaningful gap, even though the core action is communicated clearly.

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

Parameters3/5

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

Schema coverage is 75%, with guild, channel, and avatar_url documented inline, so the schema already carries most of the weight. The description loosely maps 'display name and avatar' onto the name and avatar_url params but never clarifies that name is the webhook's own label rather than a per-message override, which is a plausible source of confusion. It adds only marginal meaning beyond the schema.

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 opens with a specific verb and resource: 'Create an incoming webhook on a channel.' That is enough to separate it from delete_webhook, update_webhook, and send_webhook_message. It stops short of naming or contrasting any sibling, so it sits just below the top mark.

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 reach for this tool instead of create_channel, create_invite, or send_webhook_message, and no prerequisites such as the Manage Webhooks permission are given. The second sentence sketches a use case (posting under a custom display name/avatar) but frames it as justification rather than guidance, leaving an agent to infer the trigger conditions.

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