Skip to main content
Glama
Guildora
by az-xx

Read messages

read_messages
Read-onlyIdempotent

Retrieve recent Discord messages from channels, threads, forum posts, or DMs—including authors, replies, attachments, embeds, and reactions—and page by message ID/date or list pinned messages.

Instructions

Reads recent messages from a channel, thread, forum post or DM, shown oldest first with IDs, authors, replies, attachments (names and IDs; get_message gives URLs), embeds and reactions. Page with before/after/around (message ID or ISO date). pinned: true lists pinned messages instead. To find messages by text or author, use search_messages.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "read_messages"
  }
}

Input Schema

NameRequiredDescriptionDefault
userNoInstead of channel: a user (ID, <@mention> or name) whose DM channel to use.
afterNoOnly messages after this message ID or ISO date.
guildNoServer ID or name. Optional if DISCORD_GUILD_ID is set or the bot is in one server.
limitNoHow many messages (1-100, default 25).
aroundNoMessages around this message ID.
beforeNoOnly messages before this message ID or ISO date.
pinnedNoList pinned messages instead of history.
channelNoChannel or thread: ID, <#mention>, link, or name. Archived threads by ID or link.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.6/5.0
Behavior4/5

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

Adds substantial behavior beyond the annotations: result ordering (oldest first), the exact fields returned (IDs, authors, replies, attachment names/IDs, embeds, reactions), and a pointer to get_message for attachment URLs. Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the remaining gap is access/permission behavior for channels the bot cannot read — noteworthy given a check_access sibling exists.

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 dense paragraph that front-loads the core action and return shape before paging and the pinned alternative. Every clause carries information; nothing is redundant filler.

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?

With no output schema, the description correctly compensates by describing the returned record shape and ordering, and it explains the paging model for all three cursor parameters. The one omission for an 8-parameter, zero-required tool is the default behavior when no channel, user or guild is provided.

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 adds the semantic that before/after/around paginate and that pinned switches the whole mode of the call, which is the one behavior not obvious from the parameter list alone. Slight inconsistency: it says 'around' accepts an ISO date while the schema documents only a message ID for that parameter.

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?

States a specific verb and resource ('Reads recent messages') and enumerates the scopes it covers (channel, thread, forum post, DM). It also distinguishes itself from two siblings by name — get_message for attachment URLs and search_messages for text/author lookup — so an agent need not open either schema to choose.

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?

Explicitly routes the agent away from this tool when the goal is text or author lookup ('use search_messages') and documents the in-tool alternative mode ('pinned: true lists pinned messages instead'). The only minor gap is that it does not say what happens when no channel/user is supplied.

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