discord-mcp

discord_send_message

Send a message to a Discord channel, thread, or DM as the bot, optionally as a reply. Confirm wording first; returns the new message ID and jump link.

Instructions

Post a message to a channel, thread, or DM channel as the bot. Optionally as a reply.

Visible to everyone in the channel immediately — confirm wording with the user first.
Mentions do not ping unless allow_mentions is true.

Returns: Confirmation with the new message ID and a jump link.

Input Schema

TableJSON Schema

Name	Required	Description
`content`	Yes	Message text; Discord Markdown allowed, max 2000 chars.
`reply_to`	No	Message ID to reply to.
`channel_id`	Yes	Channel, thread, or DM channel ID.
`allow_mentions`	No	Let @user/@role/@everyone in the text actually ping. Off by default to avoid accidental mass pings.
`mention_reply_author`	No	When replying, ping the original author.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 3, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds meaningful behavior beyond them: immediate public visibility, the mention-ping gating rule, and the returned confirmation with message ID and jump link.

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?

Four short, front-loaded lines: the core action first, then the safety caveat, then the mention rule, then the return shape. No filler, and each sentence carries distinct information.

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?

For a 5-param send tool, annotations cover the safety profile, the output schema covers the return value (which the description also summarizes), and the description covers visibility and mention behavior. Nothing needed to call it correctly is missing.

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, but the description adds real semantics for allow_mentions ("mentions do not ping unless allow_mentions is true"), which is the non-obvious behavioral implication of that flag.

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?

States a specific verb and resource ("Post a message") plus the target surfaces (channel, thread, DM channel). It's clear what it does, but it doesn't differentiate from the sibling discord_send_dm, which overlaps on the DM case, so sibling disambiguation is incomplete.

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 actionable context: the message is immediately visible to everyone, so confirm wording with the user first, and mentions won't ping unless allow_mentions is set. This is clear guidance, though it never states when to prefer this over discord_send_dm or discord_edit_message.

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