Skip to main content
Glama
lburnscissp

discord-mcp

by lburnscissp

discord_send_dm

Send a direct message from a Discord bot to a user; confirm first, then reuse the returned DM channel ID to read replies.

Instructions

Send a direct message from the bot to a user.

Fails if the user has DMs from server members/bots disabled. Confirm with the user
before sending — DMs feel more personal than channel posts.

Returns: Confirmation with the DM channel ID (reuse it with discord_read_messages to see replies).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contentYesMessage text; Discord Markdown allowed, max 2000 chars.
user_idYesUser to message. They must share a server with the bot and allow DMs from it.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only declare the generic non-readOnly/non-idempotent/open-world profile; the description adds real context: the tool fails when the recipient has DMs from server members/bots disabled, that user consent should be obtained first, and that the returned DM channel ID can be reused. It stops short of stating rate limits or whether the message can be recalled, which would be the remaining gap.

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?

Three short paragraphs with the action front-loaded, then the failure/consent caveat, then the return value. Every sentence carries distinct information and nothing is redundant.

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 an output schema present, the description need not document the return payload, and it correctly refrains from doing so while still hinting at the reusable channel ID. Annotations plus schema plus description cover safety, failure mode, and follow-up path; only edge cases like rate limiting or bot-permission errors are unaddressed.

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 both user_id (pattern, DM-allowance constraint) and content (Markdown, 2000-char cap) are already documented in the schema. The description adds no syntax or format detail beyond that, 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 and resource ('Send a direct message from the bot to a user') and implicitly separates itself from the channel-post sibling by noting 'DMs feel more personal than channel posts'. An agent can tell this apart from discord_send_message 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 an explicit operational precondition ('Confirm with the user before sending') and a failure condition tied to recipient DM settings. It lacks an explicit when-not/alternative routing statement naming discord_send_message, but the context for choosing a DM is clear.

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