Skip to main content
Glama
lburnscissp

discord-mcp

by lburnscissp

discord_kick_member

Destructive

Removes a member from a Discord server and records a reason in the audit log. Requires Kick Members permission; confirm before use, as they can rejoin via invite.

Instructions

Remove a member from the server. They can rejoin with an invite. Needs Kick 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.

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 and non-idempotent, so the safety profile is covered. The description adds value beyond them: reversibility ('can rejoin with an invite'), the required bot permission, and a confirmation requirement before an irreversible-to-the-user (though recoverable) action.

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?

Four short, front-loaded sentences with no filler; the action and reversibility lead. 'Returns: Confirmation.' is slightly redundant given an output schema exists, which keeps it from a 5.

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 with an output schema, the description covers action, reversibility, permission, and confirmation gating, which is enough to call it correctly. It doesn't note failure modes (e.g., missing permission or invalid user_id) but nothing essential is missing.

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 67% (reason and guild_id are documented; user_id is not). The description adds no parameter meaning at all – no mention of user_id source/format or how guild_id defaults. Baseline 3 is appropriate when the schema does most of the work but a gap remains unaddressed.

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 ('Remove a member from the server'). Crucially, 'They can rejoin with an invite' distinguishes it from discord_ban_member without the agent needing to open either schema, and the sibling set confirms ban/timeout are the relevant alternatives.

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?

Provides the permission prerequisite ('Needs Kick Members') and an operational gate ('Confirm with the user before calling'), plus implicit selection guidance via the rejoin note. It never explicitly names ban_member/timeout_member as alternatives, so it falls short of a 5.

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