Skip to main content
Glama
lburnscissp

discord-mcp

by lburnscissp

discord_ban_member

Destructive

Bans a user from a Discord server, optionally deleting their recent messages.

Instructions

Ban a user from the server (they cannot rejoin until unbanned), optionally deleting their recent messages.

Needs Ban Members. Confirm with the user before calling.

Returns: Confirmation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonNoReason recorded in the server's audit log.
user_idYes
guild_idNoServer (guild) ID. Omit to use DISCORD_GUILD_ID from .env.
delete_message_daysNoAlso delete this user's messages from the last N days (0–7).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context: the ban persists until explicitly lifted, the required permission scope, and a mandatory user-confirmation step. It does not state whether a reason is required or what happens when the target is not currently a member.

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?

Three short, front-loaded lines with no filler; the effect statement comes first and the precondition second. 'Returns: Confirmation.' is largely redundant given an output schema exists, costing it the top score.

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 destructive moderation tool, the description covers effect, permission requirement, and confirmation policy, and the output schema handles the return value. Missing edge cases (target not in server, interaction with existing bans, audit-log reason requirements) are minor against the annotation coverage.

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 75%, with reason, guild_id, and delete_message_days all already described in the schema itself. The description's 'optionally deleting their recent messages' merely restates delete_message_days without adding format, default, or range detail, so the baseline of 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 (Ban) and resource (user from the server), and the parenthetical clarifies the durable effect ('cannot rejoin until unbanned'), which distinguishes it from kick_member and timeout_member in the sibling set.

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 concrete prerequisites and a procedural rule: 'Needs Ban Members' and 'Confirm with the user before calling.' It stops short of explicitly naming alternatives (kick/timeout/unban) and when to prefer them, so routing between the sibling moderation tools still requires inference.

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