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

Discord MCP - Discord server management MCP for AI agents

Subscribe to events

subscribe_events

Start recording real-time Discord server activity—messages, joins, reactions, role/channel changes, bans, and voice movement—into a buffer you can read with get_recent_events.

Instructions

Watch one server live: start recording real-time activity as it happens (messages, joins and leaves, reactions, channel and role changes, bans, voice movement) into a buffer you then read with get_recent_events. Only the named server's events are recorded (the default server when none is named). Use this to observe what is going on now. It is not for scheduled community events (create_event) or timed messages (schedule_message). Available types: message_created, message_deleted, member_joined, member_left, reaction_added, reaction_removed, channel_created, channel_deleted, role_created, role_updated, role_deleted, ban_added, ban_removed, voice_state_changed.

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": {
      "types": "<types>"
    },
    "name": "subscribe_events"
  }
}

Input Schema

NameRequiredDescriptionDefault
guildNoGuild (server) name or ID. Omit to use the default guild.
typesYesWhich event types to record.
channelNoOnly record events from this channel.
include_botsNoAlso record events caused by bots, including this one. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field 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"
  2. Changed1 schema field changedv1.3.0
    • removedInput schema / additionalProperties
      Removed value: -false
  3. First observedv1.0.2

TDQS

A4.3/5.0
Behavior4/5

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

Beyond the sparse annotations, the description discloses that events are buffered, scoped to one server by default, and later read through get_recent_events. It does not explain subscription lifetime, whether multiple subscriptions replace each other, or how to stop recording, which are meaningful gaps for a stateful watcher.

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?

The purpose and alternatives are front-loaded and the paragraph is easy to scan. The long enumeration of event types duplicates the schema enum and is the main source of avoidable length.

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?

For a stateful event-capture tool with no output schema, the description explains what is recorded and where to read it. It is nearly complete, but should mention unsubscribe_events or otherwise clarify how the recording is stopped and whether the buffer persists.

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 the schema already documents guild, types, channel, and include_bots. The description reinforces the default-guild behavior and lists event types, but it does not add meaning for channel filtering or include_bots, leaving this at the baseline for a fully documented schema.

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?

The description states a specific verb and resource: watch/start recording real-time activity for one server into a buffer. It clearly separates this from get_recent_events and from unrelated scheduled-event and timed-message tools.

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?

It explicitly says to use this to observe what is happening now, explains that the buffer is read with get_recent_events, and names two tools it is not for: create_event and schedule_message.

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