Exposes Discord desktop app RPC through MCP for reading server/channel/voice data, streaming events, and controlling voice/presence actions.
Get guild/server and channel information (get_guilds, get_guild, get_channels).
Read a known channel, DM, or group DM via the client-loaded message window; not full history or server-side search, and it can move the Discord view.
Check the selected voice channel and local voice settings.
Subscribe/unsubscribe to RPC events and read buffered events (subscribe, unsubscribe, get_events) for messages, voice state/speaking, guild/channel, activity, and entitlement events.
Switch text/voice channels; join or leave a call.
Adjust your voice settings or another participant’s local volume.
Toggle camera or screen sharing in a call.
Set/clear Rich Presence and accept/reject activity join requests.
Set certified device information.
Provides tools for reading and controlling Discord, including viewing servers and channels, reading messages, subscribing to events, switching channels, joining/leaving voice calls, adjusting voice settings, and managing Rich Presence.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@discord-rpc-mcp What's the latest in the #general channel?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
https://github.com/user-attachments/assets/5c26f647-2953-4cdc-b2e6-b7ea76578f2c
A server that exposes the Discord desktop app's RPC through MCP. (Functionality follows Discord's RPC capabilities, so features such as searching past chats are not available.)
Ask it to read a channel, receive new messages, or turn down someone's volume in a call.
To store authorization tokens securely, an OS credential store is required (Secret Service on Linux).
With Node.js 22+, npm and Git installed, register the MCP with your agent client as follows.
# Codex
codex mcp add discord-rpc-mcp -- npx -y github:ver-1000000/discord-rpc-mcp
# Claude Code
claude mcp add --scope user discord-rpc-mcp -- npx -y github:ver-1000000/discord-rpc-mcpClients that support MCPB can install the .mcpb file from Releases.
Once the MCP is installed and enabled, tell your agent: Set up discord-rpc-mcp.
The setup tool opens a local page that guides you through creating your own Discord application, enabling Public Client and entering its Client ID.
For manual installation or detailed instructions, see the installation guide.
Related MCP server: DiscordMCP
Tools | Purpose |
| Get server and channel information |
| Read a channel, DM or group DM; optionally select response fields |
| Check your voice channel and settings |
| Subscribe to and read messages, voice events and more |
| Switch channels, join or leave a call |
| Adjust your audio settings or another participant's local volume |
| Toggle the camera or screen sharing in a call |
| Set or clear Rich Presence |
| Accept or reject activity join requests |
| Set device information |
Usage · Development · Discord RPC access requirements · Terms of Use · Privacy Policy
Read a known channel, DM or group DM. Only the client-loaded message window is available; this can move the Discord view. It is not full history or server-side search.
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important side effects and limitations beyond the annotations: it can move the Discord view, only the client-loaded message window is available, and it is not full history or server-side search. This is valuable context given that readOnlyHint is false and idempotentHint is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and every sentence adds essential information. There is no filler or repetition of schema/annotation data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, no output schema, and the annotations already provided, the description covers purpose, scope, side effects, and limitations. An agent has enough information to decide when to call it and what to expect from the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does convey that the single parameter identifies a known channel, DM, or group DM, but it doesn't elaborate on how channel_id maps to those resource types or add meaningful detail beyond the schema's name and pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read'), a specific resource ('a known channel, DM or group DM'), and key scoping details. It is clearly distinguishable from sibling tools like get_channels, get_guild, and get_selected_voice_channel without needing to open schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for reading an already-known channel/DM/group DM, not for searching or retrieving full history. It explicitly says it is not server-side search, which helps an agent avoid misusing it, though it doesn't name an alternative tool for full-history search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List channel metadata for a guild.
| Name | Required | Description | Default |
|---|---|---|---|
| guild_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description carries less burden here. It adds guild scoping, which is consistent with annotations, but does not disclose pagination, ordering, permission requirements, or exact metadata fields returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler or repetition. It communicates the core operation immediately and earns high marks for conciseness, even though more behavioral detail could have been added.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, annotation-rich read-only tool, the description is minimally sufficient: it identifies the resource, scope, and list-like return. However, it leaves return-field specifics and alternative routing to the agent's inference, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. 'For a guild' loosely maps to guild_id, but the meaning is already carried by the parameter name and pattern. No additional format, optionality, or behavior details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('List'), a concrete resource ('channel metadata'), and a clear scope ('for a guild'). The plural 'channels' and guild scope distinguish it from siblings like get_channel and get_guild, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'for a guild' phrase implies the intended context, but the description gives no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as get_channel for a single channel. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the bounded in-memory event buffer. Pass nextCursor as after on subsequent calls. Does not connect to Discord or fetch historical messages.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the buffer is bounded and in-memory, there is no network/Discord access, and the tool supports cursor-based pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences front-load the core action, then provide pagination guidance and a clear boundary of what the tool does not do. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple cursor-based read tool: it explains what is read, how to paginate, and what is out of scope. It does not explicitly describe the response shape or name the response field that carries nextCursor, but this is a minor gap given the lack of an output schema and the bounded-buffer simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies that `after` represents a cursor value (`nextCursor`), which the bare numeric schema does not convey. `limit` is not explicitly described, but its default, minimum, and maximum are present in the schema and its purpose is reasonably inferable from the pagination context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names an exact action and resource: 'read the bounded in-memory event buffer.' It also explicitly distinguishes itself from Discord/historical fetching, making it clear how this tool differs from the sibling get_* tools that access guilds, channels, or voice settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete usage pattern: 'Pass nextCursor as after on subsequent calls' for pagination. It also states exclusions ('does not connect to Discord or fetch historical messages'), though it does not explicitly name an alternative sibling or an exact when-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one guild by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No | ||
| guild_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no behavioral context beyond that—no mention of not-found behavior, permissions, rate limits, or return format. It is neutral and does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that states the action and target without filler. It is well under any length concern and front-loads the most relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two parameters, rich safety annotations, and no output schema, the description covers the core action and target. It does not specify behavior for missing guilds or timeout units, but these are secondary; the tool is adequately characterized for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema_description_coverage at 0%, the schema offers no parameter descriptions. The description clarifies the purpose of guild_id through 'by ID,' but it does not address the optional timeout parameter, its unit, or its effect. This is insufficient compensation for the complete absence of schema-level parameter docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a specific resource ('guild'), and scope qualifiers ('one', 'by ID'), which clearly distinguish it from the plural sibling get_guilds that presumably lists guilds. The singular target makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like get_guilds. The 'by ID' phrasing implies the intended context (fetch a single guild when its ID is known), but it never names a sibling or exclusion condition, leaving the agent to infer the choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List guild metadata available to the Discord client.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, non-destructiveHint, and openWorldHint, so the safety profile is clear. The description adds minimal behavioral context beyond the phrase 'available to the Discord client'; it does not detail return behavior, data freshness, or any client-connection requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the operation and the resource immediately, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter list operation, the description is adequately complete: it indicates the result type (a list of guild metadata) and the data scope (what the Discord client has available). There is no output schema, so slightly more detail about the returned metadata fields could improve completeness, but it is not necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is effectively 100%, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('guild metadata'), and signals a plural, list-style operation that distinguishes it from singular counterparts like get_guild. The scope 'available to the Discord client' further clarifies what data is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a list of guild metadata is needed, but it does not explicitly state when to prefer it over get_guild or mention any other alternatives. There are no exclusions or conditional guidance, so usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the currently selected voice channel, or null.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds the useful behavioral detail that the result may be null, which is not fully captured by the annotations. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one concise sentence that front-loads the action and resource while also disclosing the null return state. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with strong annotations, this description is complete: it states what is returned, the null possibility, and the selection context. An agent has enough information to invoke it correctly without additional explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description has no parameter burden. The schema is empty and fully covered, so the baseline of 4 applies; no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Get', and names a precise resource: the currently selected voice channel. It also explicitly states the null case, which distinguishes this from generic channel getters like get_channel or get_channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'currently selected voice channel' implies when the tool is appropriate, but the description gives no explicit guidance about when to use this over siblings like get_voice_settings or get_channel, nor does it state any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get local voice settings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds a 'local' qualifier that hints at scope, but does not disclose return format, potential edge cases, or any other behavioral details beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, front-loaded sentence with no filler. Every word ('Get', 'local', 'voice settings') contributes meaning, and there is no redundant information or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, annotations covering safety), the description is minimally adequate but leaves ambiguity around what 'voice settings' actually includes and what the returned data looks like. More specific return details would improve completeness without bloating the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is trivially 100%. Per the baseline for parameterless tools, the description is not required to explain parameters, and it correctly adds nothing irrelevant. No parameter-related gaps exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('local voice settings'), which clearly differentiates it from siblings like get_selected_voice_channel that deal with channels rather than settings. The term 'local' adds a scoping detail, though it could be more explicit about what constitutes voice settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. Sibling tools such as get_selected_voice_channel or get_events are not mentioned, and no context is provided about typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subscribe to an RPC event. Channel events require channel_id; GUILD_STATUS requires guild_id. Read received events with get_events. Subscribe again after a connection gap. Additional Discord scopes may be required.
| Name | Required | Description | Default |
|---|---|---|---|
| event | Yes | ||
| guild_id | No | ||
| channel_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey idempotency and non-read-only status. The description adds context beyond those hints: subscriptions are not persistent across connection gaps ('Subscribe again after a connection gap') and may require extra authentication scopes. However, it does not describe what the response looks like or behavior on duplicate subscriptions, which are minor gaps given the idempotentHint true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences each carry distinct information: purpose, parameter requirements, event retrieval, resubscription, and scope prerequisites. There is no redundancy or filler, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (3 params, no output schema, no nested objects), the description covers the essential call flow and constraints. Missing are a full event-to-ID mapping and what response to expect after subscribing, but the presence of get_events implies the read path. Overall, an agent can invoke it correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter meaning. It clarifies that channel events require channel_id and GUILD_STATUS requires guild_id, which is useful, but it does not map out which of the 23 enum events qualify as 'channel events.' This leaves ambiguity for an agent invoking with only the enum list and no further guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Subscribe to an RPC event.' It clearly distinguishes this from siblings by noting the complementary actions of reading events with get_events and resubscribing after gaps, so an agent can tell it apart from unsubscribe and get_events without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: subscribe to start receiving events, then read with get_events, and resubscribe after a connection gap. It also mentions 'Additional Discord scopes may be required,' which is a prerequisite condition. This is concrete usage guidance beyond a generic purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unsubscribe using the same event and target IDs used to subscribe.
| Name | Required | Description | Default |
|---|---|---|---|
| event | Yes | ||
| guild_id | No | ||
| channel_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotence and non-destructive behavior, so the description does not need to restate those. The description adds the important requirement that IDs must match the original subscription, which is useful behavioral context, but it does not disclose any side effects, error behavior, or authentication expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no filler. The core instruction (unsubscribe) comes first, followed immediately by the only necessary qualification (matching the original IDs). Every word contributes to the agent's ability to call the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple unsubscribe operation with no output schema, the description is largely complete: it states what to do and how to select parameters. The annotations add safety and idempotence context, and the schema fully enumerates valid event values and ID formats. A brief note about return values or behavior when no subscription exists would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'event' and 'target IDs' (presumably guild_id and channel_id) should be the same values used during a prior subscribe call, which adds useful semantic meaning beyond the raw enum and patterns. However, it does not explicitly map 'target IDs' to the optional parameter names or clarify required/optional roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific action ('Unsubscribe') and the key context for that action: use the same event and target IDs previously used to subscribe. This distinguishes it from the sibling 'subscribe' tool and other getter tools by linking it directly to the subscription lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'using the same event and target IDs used to subscribe' provides actionable usage guidance: this tool is intended to reverse a prior subscription with matching parameters. It does not explicitly name when not to use it or mention alternatives, but the context is clear enough for an agent to avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_channelget_channelsget_eventsget_guildget_guildsget_selected_voice_channelget_voice_settingssubscribeunsubscribeScored across 9 tools
Each tool targets a distinct concern: voice state, event subscription, guild/channel lookup, and the event buffer. The singular/plural pairs like get_guild vs get_guilds and get_channel vs get_channels are clearly separated by their descriptions.
The retrieval tools consistently follow a get_<resource> pattern using lowercase snake_case. subscribe and unsubscribe deviate by being verb-only, but they form a clear paired command group, so the mix is minor rather than confusing.
Nine tools is a well-scoped size for a Discord RPC client surface: voice/event tools plus guild/channel lookup tools cover the core use case without redundancy. Each tool has a clear purpose and the set does not feel bloated.
The set covers the main read-only Discord RPC workflows: retrieving guilds, channels, voice state, and subscribing to/reading events. It lacks mutating RPC operations like set_voice_settings or activity control, but those appear to be outside the server's apparent monitoring-oriented scope.
Connect a Discord bot (bot token from the developer portal) to read/send messages, list guilds and c
Control your Discord community: send/read messages, manage channels and forums, and handle webhook…
Connect AI assistants to authorized Windows and macOS devices for files, commands, and management.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
