mcp-discord

discord_send_message

Send messages to Discord channels with text, embeds, replies, and mention controls. Use this tool to post content and manage communication in Discord servers programmatically.

Instructions

Send a new message to a Discord channel. Supports plain text, embeds, replies, and allowed_mentions control. Returns the created message object including its ID.

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_id": "<channel_id>"
    },
    "name": "discord_send_message"
  }
}

Input Schema

Name	Required	Description
`channel_id`	Yes	Snowflake ID of the target channel.
`content`	No	Message text (up to 2000 chars). Either content or embeds is required.
`embeds`	No	Array of Discord embed objects (up to 10). Each embed is a rich card with title, description, fields, color, etc.
`reply_to_message_id`	No	Optional — reply to this message ID. The message must be in the same channel.
`allowed_mentions`	No	Control which mentions actually ping. E.g. {"parse": ["users"]} to allow user pings but suppress @everyone.
`suppress_embeds`	No	If true, no link previews are auto-generated.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Apr 23, 2026

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Send a new message') and return value ('Returns the created message object including its ID'), which implies a write operation with output. However, it lacks details on permissions required, rate limits, error conditions, or side effects (e.g., message visibility, notifications), leaving gaps in behavioral context for a mutation tool.

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?

The description is front-loaded with the core purpose in the first sentence, followed by key features and return value in a second sentence. Every sentence earns its place by adding value (e.g., listing capabilities, specifying output), with zero waste or redundancy, making it efficiently structured and appropriately sized.

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?

Given the tool's complexity (6 parameters, mutation operation) and lack of annotations and output schema, the description is partially complete. It covers the basic action, features, and return value, but for a mutation tool, it should ideally include more behavioral context (e.g., permissions, errors) or output details. The schema compensates for parameter documentation, but overall completeness is adequate with clear gaps.

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 description coverage is 100%, so the schema already documents all 6 parameters thoroughly (e.g., channel_id as 'Snowflake ID of the target channel', content with char limits). The description adds minimal value beyond the schema by mentioning 'plain text, embeds, replies, and allowed_mentions control', which loosely maps to parameters but doesn't provide additional syntax or format details. Baseline 3 is appropriate as the schema does the heavy lifting.

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 action ('Send a new message') and resource ('to a Discord channel'), distinguishing it from siblings like discord_edit_message (edits existing messages) or discord_send_typing (shows typing indicator). It specifies the tool's capabilities (plain text, embeds, replies, allowed_mentions control) and return value, making the purpose highly specific and differentiated.

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 implies usage context by listing supported features (e.g., embeds, replies), which helps an agent decide when to use this tool versus alternatives like discord_edit_message for updates or discord_send_typing for non-message actions. However, it lacks explicit when-not-to-use guidance or direct sibling comparisons, such as clarifying that discord_bulk_delete_messages is for removal, not sending.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.