discord-admin-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource-action combination: bot info, guild info, roles (list/assign/remove/create/delete), channels (list/create/edit/delete), members (kick/ban/unban/timeout), and message purging. There is no obvious overlap; even similar actions like assign_role vs remove_role are clearly differentiated by verb.
Naming Consistency5/5
All 17 tools follow a consistent snake_case verb_noun pattern (e.g., list_roles, create_channel, kick_member). The verbs clearly indicate the action and nouns denote the resource, with no mixed styles or vague names.
Tool Count4/5
With 17 tools, the server is slightly above the ideal 3-15 range but remains well-scoped for a Discord admin server covering multiple domains (roles, channels, members, moderation). Each tool serves a distinct purpose, and the count feels justified rather than bloated.
Completeness4/5
The tool surface covers core admin workflows: full role lifecycle (create/list/delete/assign/remove), channel create/edit/delete/list, and member moderation (kick/ban/unban/timeout). Minor gaps exist, such as no role editing or channel moving, but the current set is sufficient for typical admin tasks without dead ends.
Average 3.3/5 across 16 of 17 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. Deleting a channel is destructive and likely irreversible, yet the description does not mention permanence, permission requirements, or effects on messages/history. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short, it is under-specified rather than appropriately concise. It contains only one trivial sentence that restates the tool's name. It doesn't earn its place because it fails to provide essential context expected for a destructive operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is destructive, has no annotations, and no parameter coverage. Although an output schema exists, the description omits critical details about permissions, side effects, and reversibility. For a simple but dangerous operation, this level of incompleteness is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 by explaining parameters. It does not mention channel_id or reason, nor does it clarify their purpose, format, or optionality beyond what the schema already shows. The description adds zero semantic value for parameters.
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?
The description clearly states the action (delete) and resource (a Discord channel). It's unambiguous, but doesn't differentiate from sibling tools like create_channel or edit_channel, nor does it specify any scope or constraints. It meets the 'clear but no sibling differentiation' criterion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, what permissions are required, or any prerequisites. No alternatives or exclusions are mentioned. The description provides no usage context beyond the bare action, amounting to 'no guidance'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing side effects. It only states 'kick a member' without noting that the member can rejoin, that permissions may be required, or that the action is reversible. This is a minimal disclosure that leaves important behavioral traits unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), which is concise but not proportional to the information needed. It front-loads the core action but omits essential context, making it too terse rather than appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature, lack of annotations, and 0% schema coverage, the description is far from complete. It does not explain return values (though an output schema exists), prerequisites, or the difference from ban/timeout. For a simple tool it still leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any parameters (user_id, reason, guild_id). It provides no additional meaning beyond the bare parameter names in the schema, failing to compensate for the lack of schema documentation.
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?
The description clearly states the action (kick) and the resource (member), making the purpose unambiguous. However, it does not differentiate from sibling tools like ban_member or timeout_member, so it misses the distinction that would earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that kick is temporary while ban is permanent, or when a timeout might be preferred. Without explicit usage context, an agent cannot make an informed choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does not mention potential side effects, permission requirements, rate limits, or what happens on failure (e.g., duplicate role names). The description is too brief to inform the agent about behaviors beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and to the point, with no redundant information, but it is under-specified. It front-loads the core action but lacks necessary context, so it is not as helpful as a slightly longer version that adds usage or behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (7 parameters, output schema exists), the description is insufficient. The output schema exists, so return values are partially covered, but the description does not address how parameters interact, what the response contains, or any constraints. For a creation tool, more context is needed to ensure correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 0% of parameters in the description, so the description must compensate, but it does not. It mentions no parameter details at all, leaving the agent to infer meaning from the schema. With 7 parameters, this is a significant gap. Even the default values are present in the schema, but the description does not clarify concepts like 'hoist' or 'mentionable' beyond the schema.
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?
The description clearly states the action ('Create a new role') and the resource ('in the server'), distinguishing it from sibling tools like assign_role, remove_role, and list_roles. It does not explicitly contrast with these alternatives, but the verb 'create' plus 'role' sufficiently conveys its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., required permissions, existing guild context), nor does it explain when to choose create_role over assign_role or edit_channel. The description is minimal and lacks contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavioral aspects, but it only says 'Delete a role.' It does not mention irreversibility, required permissions, cascading effects on members with the role, or any side effects, leaving the agent underinformed about the destructive nature.
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?
The description is a single, concise sentence with every word earning its place. It is front-loaded and easy to parse, though it sacrifices detail for brevity, which is appropriate for such a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with three parameters and many similar sibling tools, the description is incomplete. It lacks any mention of side effects, prerequisites, or how it differs from remove_role, leaving ambiguity in a context where precision matters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain any of the three parameters. The purpose of 'reason' and 'guild_id' is not clarified, and the description does not compensate for the schema's lack of descriptions.
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?
The description clearly states the action (delete) and resource (role) within the server context. It is precise and understandable, though it does not distinguish itself from sibling tools like remove_role, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as remove_role or assign_role. There is no mention of prerequisites, side effects, or scenarios where this tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states a mutation ('modify') but does not mention permissions, reversibility, side effects, or what happens with unspecified fields. This is insufficient for a mutation tool.
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?
The description is a single sentence with no fluff. It is front-loaded and to the point, fully acceptable in terms of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no annotations, the description is too sparse. It does not explain the intended use cases, parameter semantics, or typical scenarios. Even though an output schema exists, the description still lacks essential context for proper selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds almost no meaning beyond the schema. It vaguely refers to 'settings or topic' but does not clarify the role of 'reason' or that 'nsfw' is a flag. The description fails to compensate for the lack of schema descriptions.
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?
The description clearly states the tool modifies a Discord channel, which distinguishes it from delete/create/list tools. However, 'settings or topic' is generic and doesn't enumerate specific fields like name or nsfw, so it's clear but not maximally specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like delete_channel or create_channel. The description does not mention context, prerequisites, or exclusions, leaving the agent to infer usage from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not mention side effects, permissions, or whether the operation is read-only. It provides no behavioral details beyond the basic function.
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?
The description is concise and to the point, with no unnecessary fluff. However, it could be slightly more detailed without becoming verbose, hence a 4 instead of 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context: it does not mention what happens when guild_id is null, the exact return format, or any error conditions. It provides only a high-level summary, which is insufficient for complete usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, guild_id, has no description in the schema and the tool description does not explain its purpose, format, or optionality. The description mentions 'about a Discord server' but never links it to the parameter, leaving semantics ambiguous.
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?
The description clearly states the tool's function: 'Get detailed information about a Discord server' and lists example data fields. This distinguishes it from sibling tools like list_guilds, which likely return summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool versus alternatives (e.g., list_guilds) or whether the guild_id parameter is required or optional. It lacks context on invocation scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action. It does not mention required permissions, potential errors, or effects on the user's status beyond unbanning.
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?
The description is a single, concise sentence with no unnecessary words. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no annotations, and no schema descriptions, the description is severely inadequate. It neither explains parameter roles nor provides behavioral context, making it difficult for an agent to use the tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description does not explain any parameters. The meaning of user_id, reason, and guild_id is left entirely to the agent to infer.
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?
The description 'Unban a user from the server.' uses a specific verb and resource, clearly identifying the action as reversing a ban. It implicitly distinguishes from sibling tools like ban_member and kick_member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor are any prerequisites or conditions mentioned. The usage is only implied by the tool name and the brief description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions the optional message deletion window, which is a nice touch, but omits critical information for a ban operation: irreversibility, permission requirements, impact on server invites, or the fact that the user must rejoin via invite. The description could be much more transparent about the destructive nature of the action.
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?
The description is a single, well-structured sentence that front-loads the core action and immediately provides a useful parameter constraint. Every word earns its place with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with four parameters and no annotations, the description is too sparse. It doesn't mention permissions, consequences, or behavior when optional parameters are omitted. While an output schema exists and may cover return values, the lack of operational context and the potential for misuse from unclear side effects make this description incomplete for a ban operation.
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?
The description adds value by constraining delete_message_seconds to a range (0-604800), which is not present in the schema (which only specifies integer and default 0). However, the other three parameters (user_id, guild_id, reason) receive no descriptive attention. The description partially compensates for the schema's lack of detail but leaves gaps.
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?
The description uses the specific verb 'Ban' and names the resource ('a user from the server'), making the action immediately clear. It distinguishes itself from sibling tools like kick_member and timeout_member. The added detail of the message deletion window range (0 to 604800 seconds) adds useful specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to prefer this tool over alternatives such as timeout_member or kick_member, and no prerequisites or exclusions are mentioned. The optional deletion window range is the only contextual hint, but it is more of a parameter detail than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of explaining side effects and failure modes. It only mentions permission requirements but does not disclose potential errors (e.g., role not found, user not in server), whether the operation is idempotent, or any audit logging. This is minimal transparency for a mutating action.
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?
The description is one concise sentence, with no redundant words or filler. It efficiently conveys the core action and a key prerequisite, maintaining excellent brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the primary purpose and a critical precondition (permissions), but it omits details about parameters, return behavior, and error handling. It is adequate for a basic understanding but leaves gaps that a user might need to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the parameters explicitly. While user_id and role_id are inferable from the verb 'assign role', the optional guild_id and reason are not clarified. The description adds little to the bare schema, leaving parameter meaning largely unspecified.
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?
The description clearly states the tool's purpose: assigning a role to a server member. It uses the specific verb 'assign' and specifies the resource (role) and target (server member), making the intent unambiguous. It also mentions required permissions, which further clarifies the action's scope.
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 provides basic context about when to use the tool (assigning roles) but does not explicitly contrast with sibling tools like remove_role or indicate scenarios where this tool should not be used. The permission requirement gives some guidance, but it lacks clear alternative or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose that the operation is read-only or non-destructive, nor does it mention any permissions or side effects. The description only restates the basic purpose without adding behavioral context.
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?
A single, clear sentence that is front-loaded with the core action and resource. No fluff or redundancy—every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema exists, so return structure is covered. However, the description does not clarify the behavior when guild_id is null (which could mean listing across all servers), leaving a meaningful gap for a parameter that is optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (guild_id) with 0% description coverage. The description's phrase 'in a server' hints at the parameter but does not explain its name, type, or what happens when it is null/default. This is insufficient given the low schema coverage.
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?
The description clearly states the action (list), resource (channels), scope (in a server), and specifies the fields returned (names, types, categories, topics). This distinguishes it from sibling tools like get_guild_info (server metadata) and channel mutation tools.
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 usage is implied: it's used to list channels in a server. However, no explicit guidance is given about when to prefer this over alternatives (e.g., get_guild_info) or when not to use it (e.g., when needing a single channel's details).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not mention side effects, read-only nature, permission requirements, or error scenarios. Since the description carries the full burden, it fails to disclose potential behavioral aspects.
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?
The description is a single, focused sentence that efficiently conveys the tool's purpose and the returned fields. There is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides basic return information (IDs, names, permissions, positions) but lacks details on response format, possible errors, or parameter usage. Given the tool's simplicity, it is moderately complete but leaves gaps for a new agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (guild_id) has no schema description, and the tool description does not explain what it represents or how it is used. With 0% schema coverage, the description must compensate, but it only implies the server context without clarifying the parameter.
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?
The description explicitly states the action (list all roles) and the resource (Discord server), along with the specific data returned (IDs, names, permissions, positions). It clearly distinguishes from sibling tools like list_channels or get_guild_info.
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 implies when to use it (when you need role information for a server) but does not explicitly mention alternatives or provide contextual guidance like 'use this when you need role details'. It lacks a comparative note found in higher-scoring examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It details the channel_type integer mapping, but omits side effects (e.g., success behavior, return value), permission requirements, or handling of duplicate names. It lacks depth for a creation tool.
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?
The description is two sentences, front-loaded with the primary action, and the second sentence efficiently lists channel_type enumerations. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params) and lack of annotations, the description covers only the channel_type facet. It does not mention required permissions (e.g., MANAGE_CHANNELS), the relationship between parent_id and channel_type, or default behavior for guild_id. The output schema exists, covering return structure, so that gap is mitigated, but overall completeness is moderate.
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 description coverage is 0%, but the description partially compensates by explaining channel_type values, which is highly valuable. Other parameters like name, topic, reason, guild_id, and parent_id are not explained beyond their self-explanatory names, leaving semantic gaps (e.g., guild_id default meaning).
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?
The description clearly states 'Create a new channel in the server' with a specific verb and resource, distinguishing it from sibling tools like edit_channel or delete_channel. The explicit channel_type enumeration adds specificity, clarifying the tool's scope.
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 implies usage (to create a channel) but offers no explicit guidance on when to use this tool versus alternatives, prerequisites like permissions, or cases to avoid. The channel_type mapping provides some context but not comparative usage details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses permission requirements and the bot role hierarchy check, but does not describe return behavior, error conditions, or side effects beyond the role removal itself. Some behavioral context is present, but gaps remain.
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?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to the action and prerequisite, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the description captures its core purpose and prerequisites. However, the optional reason and guild_id parameters are entirely unaddressed, and the description does not mention the existence of an output schema. Given the 0% schema description coverage, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain parameters like reason or guild_id. While it implicitly references user_id and role_id via 'server member' and 'role', it lacks explicit parameter guidance, leaving agents to infer from parameter names alone.
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?
The description clearly states the action: 'Remove a role from a server member.' It specifies the resource (server member) and the operation (remove role), distinguishing it from sibling tools like assign_role and delete_role.
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?
The description provides clear context for usage by stating prerequisites: 'Requires Manage Roles permission and bot role higher than target role.' This tells agents when the tool can be used but does not explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the 14-day restriction but does not explicitly emphasize that deletions are permanent or that the operation is destructive, which is important for a delete tool. It also doesn't mention permission requirements. This is a partial 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?
The description is a single, concise sentence that front-loads the core purpose. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (which covers return values), the description lacks clarity on edge cases such as what happens if count exceeds 100 or if messages are older than 14 days (fail vs. skip). It also omits permission prerequisites, but the core function is conveyed. Given the simplicity of the operation, it is mostly adequate but not fully comprehensive.
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 description coverage is 0%, so the description must compensate. It implies count is the number of messages and channel_id identifies the channel, but it does not explain the 'reason' parameter at all. It adds some context but leaves one parameter underspecified.
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?
The description clearly states the action (bulk delete), the resource (messages), and the scope (up to 100 recent messages in a channel). It distinguishes from sibling tools like delete_channel by focusing on message-level deletion.
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?
It specifies when to use (bulk delete recent messages) and includes a key limitation (messages older than 14 days cannot be bulk deleted), which helps the agent decide applicability. However, it does not explicitly mention alternatives or exclusions, though no direct sibling serves the same purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the core behavior (mute/quarantine), duration-based removal, and the 0 sentinel. However, it does not mention permission requirements, side effects on existing timeouts, or duration limits, which would be valuable for a moderation write operation.
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 tight sentences, front-loaded with the primary action followed by the critical edge case. No wasted words or repetitive detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core usage is clear, and the presence of an output schema reduces the need to document return values. However, for a no-annotation moderation tool, it lacks permission context, error/limit behavior, and explicit guidance on when to prefer timeout over kick/ban.
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 description coverage is 0%, so the description must compensate. It does add useful semantics for duration_seconds (unit and 0-to-remove behavior), but largely restates 'duration in seconds' and does not explain guild_id defaults or reason usage beyond the schema titles.
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?
The description uses a specific verb and resource: 'Timeout (mute/quarantine) a member' with a clear duration mechanism. The temporary/mute nature distinguishes it from sibling moderation tools like kick_member, ban_member, and unban_member.
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?
It clearly explains the main usage—timeout for a duration in seconds—and explicitly covers the special case of 'Set duration_seconds to 0 to remove timeout.' It does not explicitly name alternatives for permanent actions, but the core context and edge case are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states a constraint (the bot must be in the guilds) but does not explicitly indicate that the operation is read-only or free of side effects. Since it is a listing operation, this is safe to assume, but the description does not confirm it, leaving some ambiguity.
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?
The description is a single, efficient sentence that states the action and scope. It is front-loaded with the verb 'List' and contains zero unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and an output schema present, the description is complete. It clearly defines what is listed and the condition (guilds the bot is in), and the output schema covers return structure. No further details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially complete. The description adds no parameter-specific information because there is nothing to describe. Baseline for zero parameters is 4, which is appropriate.
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?
The description clearly states the action (list) and the resource (all Discord servers the bot is in). It distinguishes from the sibling tool get_guild_info, which presumably fetches a specific guild's details, by emphasizing the scope is all guilds.
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 does not explicitly mention when to use this tool versus alternatives. It implies a broad overview use case, but does not state 'use this to get an overview of guilds' or direct users to get_guild_info for specific details. For a zero-argument tool, this is acceptable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Get' implies a read-only operation and no side effects, but the description does not explicitly state this or disclose any potential caveats (e.g., authentication requirements or rate limits). It is minimally transparent but not misleading.
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?
The description is a single sentence that immediately states the tool's purpose and lists representative fields. It is concise, front-loaded, and contains no filler.
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 zero-parameter tool with an output schema, the description is sufficient. It tells the agent what the tool does without needing to explain return values (covered by the output schema). A higher score would require explicit mention of when this is useful, but the purpose is already self-evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 100%, so the description does not need to explain parameter meanings. The baseline of 4 applies because there are no parameters to describe.
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?
The description uses a specific verb ('Get') and resource ('the bot itself'), clearly distinguishing it from sibling tools that operate on guilds, roles, or channels. It also names example fields (ID, username, avatar), making the purpose immediately understandable.
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?
The phrase 'details about the bot' provides a clear context for when to use this tool—whenever you need the bot's own identity. No exclusions or alternatives are needed since no sibling tool covers this functionality, and the simple nature of the operation makes the guidance sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![discord-admin-mcp MCP server](https://glama.ai/mcp/servers/CommanderBiz/discord-admin-mcp/badges/card.svg)](https://glama.ai/mcp/servers/CommanderBiz/discord-admin-mcp)

Score Badge

Copy to your README.md:

[![discord-admin-mcp MCP server](https://glama.ai/mcp/servers/CommanderBiz/discord-admin-mcp/badges/score.svg)](https://glama.ai/mcp/servers/CommanderBiz/discord-admin-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CommanderBiz/discord-admin-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server