Skip to main content
Glama
lburnscissp

discord-mcp

by lburnscissp

discord_list_bans

Read-onlyIdempotent

Retrieve banned users from a Discord server with the reason recorded for each, returning a Markdown table or JSON list. Requires Ban Members permission.

Instructions

List banned users and the reason recorded for each. Needs Ban Members.

Returns: Markdown table (user, reason) or JSON list of {user_id, username, reason}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
guild_idNoServer (guild) ID. Omit to use DISCORD_GUILD_ID from .env.
response_formatNo'markdown' for reading, 'json' for full structured data.markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description still adds the permission requirement and the exact output shapes, which are not in the annotations. It does not mention pagination behavior for the limit, a minor omission.

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?

Two short sentences with the action front-loaded and a labeled 'Returns:' clause; every phrase carries information and nothing is padded.

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?

An output schema exists so return values need not be described, yet the description restates them helpfully and covers the auth prerequisite. The only gap is the undocumented limit parameter, which is minor for a read-only list tool.

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%: guild_id and response_format are documented in the schema while limit is not. The description reinforces response_format by spelling out what 'markdown' vs 'json' produce, but adds nothing about the limit parameter, so it only partially compensates for the gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List banned users') plus the payload it returns ('the reason recorded for each'), making it clearly distinct from the ban/unban siblings. It stops short of naming a sibling to route against, so it is clear but not maximally differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description supplies a prerequisite ('Needs Ban Members'), which is genuine usage context, but offers no when-to-use vs when-not guidance and never points to alternatives such as discord_get_audit_log or discord_unban_member. Usage is implied by the name rather than stated.

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