Skip to main content
Glama
Discord MCP - Discord server management MCP for AI agents

Discord MCP - Discord server management MCP for AI agents

Reply to forum post

reply_to_forum_post

Adds a reply inside a Discord forum post using text, embeds, or both, so agents can answer threads by post title or thread ID.

Instructions

Add a reply inside a forum post: text, embeds, or both.

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": {
      "post": "<post>"
    },
    "name": "reply_to_forum_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
postYesPost title or thread ID.
guildNoGuild (server) name or ID. Omit to use the default guild.
embedsNoUp to 10 embeds. Each needs a title, a description, an author, fields, a footer, or a picture. Discord allows 6,000 characters of text across all of one message's embeds.
contentNoReply text. May be left out when embeds carry the reply.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields 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"
    • addedInput schema / properties / content / description
      Added value: +"Reply text. May be left out when embeds carry the reply."
    • changedInput schema / properties / embeds / description
      Previous value: -"Up to 10 embeds."New value: +"Up to 10 embeds. Each needs a title, a description, an author, fields, a footer, or a picture. Discord allows 6,000 characters of text across all of one message's embeds."
    • addedInput schema / properties / embeds / items / additionalProperties
      Added value: +false
    • addedInput schema / properties / embeds / items / properties / author
      Added value: +{
      +  "description": "Small line above the title, such as who it is from.",
      +  "maxLength": 256,
      +  "type": "string"
      +}
    • addedInput schema / properties / embeds / items / properties / fields
      Added value: +{
      +  "description": "Up to 25 name and value pairs under the description.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "inline": {
      +        "description": "Sits beside its neighbours instead of on a row of its own.",
      +        "type": "boolean"
      +      },
      +      "name": {
      +        "maxLength": 256,
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "value": {
      +        "maxLength": 1024,
      +        "minLength": 1,
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "name",
      +      "value"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 25,
      +  "type": "array"
      +}
    • addedInput schema / properties / embeds / items / properties / footer
      Added value: +{
      +  "description": "Small line at the bottom.",
      +  "maxLength": 2048,
      +  "type": "string"
      +}
    • addedInput schema / properties / embeds / items / properties / image_url
      Added value: +{
      +  "description": "Large picture under the text: an http or https link, or attachment://<filename> for a file that comes with the message.",
      +  "maxLength": 2048,
      +  "pattern": "^(https?|attachment):\\/\\/\\S+$",
      +  "type": "string"
      +}
    • addedInput schema / properties / embeds / items / properties / thumbnail_url
      Added value: +{
      +  "description": "Small picture in the top corner, given the same way.",
      +  "maxLength": 2048,
      +  "pattern": "^(https?|attachment):\\/\\/\\S+$",
      +  "type": "string"
      +}
    • addedInput schema / properties / embeds / items / properties / timestamp
      Added value: +{
      +  "description": "A time shown beside the footer: \"now\" for the current time, or ISO 8601, like 2026-11-09T18:00:00Z. With no zone it is read as UTC.",
      +  "type": "string"
      +}
    • addedInput schema / properties / embeds / items / properties / url / description
      Added value: +"Makes the title a link."
    • removedInput schema / properties / embeds / items / properties / url / format
      Removed value: -"uri"
    • addedInput schema / properties / embeds / items / properties / url / pattern
      Added value: +"^https?:\\/\\/"
    • changedInput schema / required
      Previous value: -[
      -  "post",
      -  "content"
      -]New value: +[
      +  "post"
      +]
  2. Changed2 schema fields changedv1.3.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / embeds / items / additionalProperties
      Removed value: -false
  3. First observedv1.0.2

TDQS

B3.1/5.0
Behavior2/5

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

Annotations already declare a non-read-only, non-destructive write, which is the only behavioral signal present. The description adds nothing about visibility of the reply, required permissions, ordering, or whether the created reply is returned; for a mutation tool that is a substantial gap.

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?

A single short sentence with the verb and resource front-loaded and zero redundant wording. Nothing in it is wasted.

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?

The rich nested schema does most of the work, and no output schema exists, so the description need not explain returns. Still, a write tool with 4 parameters and no annotation detail deserves at least a note on what happens on success or what the guild default means for targeting.

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 carries all parameter meaning, including that 'content' may be omitted when embeds are supplied. The description's 'text, embeds, or both' echoes that without adding syntax, limits, or defaults, so the baseline of 3 applies.

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 states a specific verb and resource ('Add a reply inside a forum post') and names the acceptable payload shapes ('text, embeds, or both'), so an agent can distinguish it from create_forum_post or update_forum_post. It stops short of any explicit sibling differentiation, which keeps it from a 5.

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?

'text, embeds, or both' implies a content requirement, but there is no stated when-to-use guidance, no prerequisites (permissions, guild defaults), and no mention of alternatives such as creating a thread or updating an existing reply. The agent must infer context entirely.

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