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

Discord MCP - Discord server management MCP for AI agents

Catch up

catch_up
Read-only

Summarize Discord server activity in one read-only call: channels and threads with new messages since a time, busiest first, with participants, trimmed messages, @everyone pings, and member mentions.

Instructions

What happened in a server recently, in one call: every channel and thread with new messages since a time (default the last 24 hours), busiest first, with who talked, the messages themselves (trimmed), @everyone pings, and, with mentions_of, the messages that mention a member. Quiet channels are skipped without being read. Read only. For one channel's full history use read_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": "catch_up"
  }
}

Input Schema

NameRequiredDescriptionDefault
guildNoGuild (server) name or ID. Omit to use the default guild.
hoursNoHow far back to look, in hours. Default 24, at most 14 days.
sinceNoOr an exact start time in ISO 8601, such as when the user was last here.
channelsNoOnly these channels (names or IDs); a category means the channels in it. Default: every channel the bot can read.
mentions_ofNoA member name or ID; messages that mention them are listed on their own.
per_channelNoMost messages read per channel. Default 30.
max_channelsNoMost channels and threads read, taking the most recently active. Default 12.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.2

TDQS

A4.1/5.0
Behavior4/5

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

Beyond readOnlyHint=true it discloses real behavior: results are ordered busiest-first, quiet channels are 'skipped without being read', messages are returned trimmed, and @everyone pings are surfaced. The 'Read only' sentence restates the annotation but the rest adds genuine context.

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?

Front-loads the payoff ('what happened in a server recently, in one call') then packs the output shape and the sibling routing into one dense sentence. Nothing is wasted, though the central sentence is long and list-heavy.

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 7 optional params and no output schema, the description does the needed work by sketching the return shape (who talked, trimmed messages, pings, per-mention listing) and defaults. Limits like max 30 channels and 14-day windows are left to the schema, which covers them adequately.

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 100%, so hours, since, channels, mentions_of, per_channel and max_channels are already documented in the schema. The description only adds marginal meaning, notably that mentions_of lists those messages separately, so the baseline 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?

States a specific verb+resource+scope: 'what happened in a server recently, in one call' aggregating every channel and thread with new messages since a time, busiest first. It also distinguishes itself from the sibling read_messages, so an agent can pick correctly without opening either schema.

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

Usage Guidelines4/5

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

Gives a clear usage context (a whole-server recent overview in one call, default last 24 hours) and explicitly routes the single-channel full-history case to read_messages. It does not cover other exclusions, but the primary alternative is named.

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