Discord MCP - Discord server management MCP for AI agents

Create forum post

create_forum_post

Creates a new Discord forum post with a title, opening message, optional tags, and up to 10 file attachments from public URLs.

Instructions

Start a post in a forum channel: a title, the opening message, optional tags from the forum's tag list, and up to 10 files fetched from public URLs.

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": {
      "forum": "<forum>",
      "title": "<title>",
      "content": "<content>"
    },
    "name": "create_forum_post"
  }
}

Input Schema

Name	Required	Description
`tags`	No	Tag names to apply.
`files`	No	Up to 10 files to attach, each fetched from a public URL (20 MiB each). Needs the Attach Files permission.
`forum`	Yes	Forum channel name or ID.
`guild`	No	Guild (server) name or ID. Omit to use the default guild.
`title`	Yes
`content`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.4.2Nov 12, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / properties / files

Added value: +{
+  "description": "Up to 10 files to attach, each fetched from a public URL (20 MiB each). Needs the Attach Files permission.",
+  "items": {
+    "properties": {
+      "description": {
+        "description": "Alt text describing the file, read by screen readers.",
+        "maxLength": 1024,
+        "type": "string"
+      },
+      "filename": {
+        "description": "Name to show, such as chart.png. Default: taken from the URL.",
+        "maxLength": 100,
+        "minLength": 1,
+        "type": "string"
+      },
+      "spoiler": {
+        "description": "Blur it until clicked.",
+        "type": "boolean"
+      },
+      "url": {
+        "description": "Public http or https URL of the file. Local paths are not accepted.",
+        "format": "uri",
+        "type": "string"
+      }
+    },
+    "required": [
+      "url"
+    ],
+    "type": "object"
+  },
+  "maxItems": 10,
+  "minItems": 1,
+  "type": "array"
+}

Changed1 schema field changedv1.3.0Aug 12, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
First observedv1.0.2Jun 14, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations declare a non-destructive write, so the basic safety profile is already known. The description adds that files are fetched from public URLs and that tags come from the forum's tag list, which is useful behavioral context, but it omits what the schema carries about the Attach Files permission and says nothing about failure modes such as unknown tags or unreachable URLs.

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?

A single sentence, front-loaded with the verb and resource, with the payload contents following in a natural order. It is efficient, though the trailing enumeration reads as a near-restatement of the schema field list rather than adding new 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?

Given six parameters, no output schema, and thin annotations, the definition covers the core operation and the two non-obvious behaviors (public-URL file fetching, forum tag list). Missing the guild parameter and any permission/error context keeps it from fully complete, but the essentials for calling it correctly are present.

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 67%, so several parameters are already well documented (files with size limit and permission note, tag names). The description restates title/content/tags/files at a high level but never mentions the 'guild' parameter or the omit-to-use-default behavior, leaving a real gap in the description's added value.

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 names a specific verb and resource (start a post in a forum channel) and enumerates the shape of the payload: title, opening message, optional tags, files. It does not explicitly contrast itself with reply_to_forum_post or update_forum_post, but the 'start a post' framing makes the create-vs-reply distinction reasonably clear.

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

Usage Guidelines3/5

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

Usage is only implied by 'Start a post in a forum channel' — an agent can infer this is for new top-level posts in a forum, not replies or edits. There is no explicit when-to-use/when-not guidance, no mention of the required permissions, and no pointer to the sibling tools that would be wrong for this operation.

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

Deploy Server