discord-mcp

discord_crosspost_message

Publish an announcement-channel message so Discord copies it to every following channel. Use after sending in a type 5 announcement channel; regular text channels cannot be crossposted.

Instructions

Publish a message posted in an announcement channel (type 5) so Discord copies it into every channel that follows that channel. Use it after posting with discord_send_message in an announcement channel; regular text channels cannot be crossposted, and a message can be published only once, so a second call fails. Manage Messages is only needed for messages the bot did not send. Returns the published message. Bot permissions it may need: View Channel, Send Messages, Manage Messages. Changes Discord data and is not idempotent; check the result before retrying.

Input Schema

Name	Required	Description	Default
`channel_id`	Yes	ID of the announcement channel (type 5) that holds the message
`message_id`	Yes	ID of the message to publish to following channels

Output Schema

Name	Required	Description	Default
`message`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedv0.1.2Nov 4, 2026
- addedInput schema / properties / channel_id / description
```
Added value: +"ID of the announcement channel (type 5) that holds the message"
```
- addedInput schema / properties / message_id / description
```
Added value: +"ID of the message to publish to following channels"
```
- addedOutput schema / properties / message / properties / attachments / items / properties / id / description
```
Added value: +"Discord snowflake ID as a numeric string"
```
- removedOutput schema / properties / message / properties / author / properties / global_name / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / message / properties / author / properties / global_name / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- addedOutput schema / properties / message / properties / author / properties / id / description
```
Added value: +"Discord snowflake ID as a numeric string"
```
- addedOutput schema / properties / message / properties / channel_id / description
```
Added value: +"Discord snowflake ID as a numeric string"
```
- removedOutput schema / properties / message / properties / edited_timestamp / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / message / properties / edited_timestamp / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- addedOutput schema / properties / message / properties / id / description
```
Added value: +"Discord snowflake ID as a numeric string"
```
- addedOutput schema / properties / message / properties / message_reference / properties / channel_id / description
```
Added value: +"Discord snowflake ID as a numeric string"
```
- addedOutput schema / properties / message / properties / message_reference / properties / guild_id / description
```
Added value: +"Discord snowflake ID as a numeric string"
```
- addedOutput schema / properties / message / properties / message_reference / properties / message_id / description
```
Added value: +"Discord snowflake ID as a numeric string"
```
First observedv0.1.0Nov 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (readOnly=false, idempotent=false, openWorld=true), it discloses the concrete consequence of non-idempotency (a second publish fails), the precise permission rule ('Manage Messages is only needed for messages the bot did not send'), and lists the bot permissions involved. That is exactly the operational context an agent needs before a mutating call, and it reinforces rather than contradicts the annotation hints.

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?

The effect is front-loaded in the first sentence, followed by usage, constraints, and permissions in a logical order. It runs long with some overlap between the permission sentence and the trailing 'Bot permissions it may need' list, which costs a little tightness but nothing is truly wasted.

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 two-parameter mutation with an output schema (so return values need not be explained), the description covers preconditions, channel-type restrictions, one-shot semantics, and permission requirements. An agent has everything needed to call it correctly and to interpret a failure.

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%, and both parameters are already documented in the schema, including the type-5 constraint on channel_id. The description restates the announcement-channel requirement but adds no format, ID-resolution, or edge-case detail beyond what the schema supplies, so the baseline of 3 applies.

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 uses a specific verb (publish/crosspost) on a specific resource (a message in an announcement channel, type 5) and explains the resulting effect: Discord copies it into every following channel. It is clearly distinguishable from discord_send_message, which is named as the posting counterpart rather than the publisher.

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

Usage Guidelines5/5

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

It gives explicit sequencing ('Use it after posting with discord_send_message in an announcement channel'), an explicit exclusion ('regular text channels cannot be crossposted'), and an explicit failure condition ('a message can be published only once, so a second call fails'). No inference is required to pick this tool over a sibling.

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