Discord MCP - Discord server management MCP for AI agents

Get message

get_message

Read-only

Fetches a Discord message's full details—author, content, timestamps, attachments, embeds, reactions, and reply reference—and can return its images for inspection.

Instructions

Fetch one message in full: author, content, timestamps, attachments, embeds, reactions, and any reply reference. With include_images, also returns the message's pictures so you can look at them: attachments, embed images, layout media, and what a forwarded message carries.

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": "<channel>",
      "message_id": "<message_id>"
    },
    "name": "get_message"
  }
}

Input Schema

Name	Required	Description
`guild`	No	Guild (server) name or ID. Omit to use the default guild.
`channel`	Yes	Channel name or ID.
`max_images`	No	How many images to return with include_images. Default 4.
`message_id`	Yes	Message ID, or the message's link.
`include_images`	No	Return the message's images as images you can see. Off by default.
`include_flagged`	No	Also return images Discord's scanning marked as explicit, gore, or self-harm. Off by default; turn on only when the user asks to review them.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 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 / include_flagged

Added value: +{
+  "description": "Also return images Discord's scanning marked as explicit, gore, or self-harm. Off by default; turn on only when the user asks to review them.",
+  "type": "boolean"
+}

addedInput schema / properties / include_images

Added value: +{
+  "description": "Return the message's images as images you can see. Off by default.",
+  "type": "boolean"
+}

addedInput schema / properties / max_images

Added value: +{
+  "description": "How many images to return with include_images. Default 4.",
+  "maximum": 10,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / message_id / description
```
Added value: +"Message ID, or the message's link."
```

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

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered and the bar is lower. The description usefully adds the return shape (a broad set of message fields) and the conditional image-returning behavior, including that flagged media is excluded by default. It does not cover error cases (bad message_id, missing channel), or how a message link resolves to an ID.

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?

Two sentences, front-loaded with the core action and its return payload, followed by the conditional image behavior. No filler and nothing repeated from the schema.

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?

With no output schema, the description carries the job of describing return values and does so concretely; the parameters, including the image options, are covered by the schema and partially illuminated by the description. Enough is present for an agent to invoke the tool correctly.

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; the description still earns credit by explaining what include_images actually surfaces (attachments, embed images, layout media, forwarded-message media), which is meaning beyond the schema's 'images you can see'. It does not mention max_images interaction or the guild default fallback, which the schema already handles.

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 ('Fetch one message in full') and enumerates exactly what is returned: author, content, timestamps, attachments, embeds, reactions, reply reference. It distinguishes itself from lighter lookups by the 'in full' framing, but never explicitly contrasts with siblings like get_reactions, whose payload this tool overlaps.

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 implied rather than stated: fetch this when you need the complete message, and add include_images when you need to view pictures. There is no guidance on when this is preferable to alternatives (e.g. listing reactions separately) and no preconditions or exclusions given.

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

Deploy Server