Skip to main content
Glama
discord-server-mcp

discord-server-mcp

check_permissions

Read-only

Determine what a Discord member or role can actually do on a server or in a channel after role and channel overrides, and identify who can see a given channel.

Instructions

What a member or role can actually do, on the server or in one channel, after roles and channel overrides. Also answers "who can see this channel?" when only a channel is given.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_permissions"
  }
}

Input Schema

NameRequiredDescriptionDefault
botNoUse this bot (name or id) instead of choosing automatically
roleNo
memberNo
serverNoServer name or id. Optional when the bot is in one server or DISCORD_GUILD_ID is set.
channelNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description usefully adds that results are post-override computed values, not raw assignments, but says nothing about return shape or whether Discord API calls/quota are involved.

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 sentences with no filler; the primary behavior comes first and the secondary mode is clearly marked with "Also". Every clause carries information an agent would otherwise have to guess.

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?

For a 5-parameter permission-resolution tool with no output schema and 40% parameter coverage, the description covers the conceptual model but leaves the response content and the bot parameter unaddressed. That is adequate but not fully self-sufficient.

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?

Schema coverage is 40% (role, member, channel, bot undocumented), so the description has real work to do, and it does clarify the key semantics: role vs. member as targets and the channel-only mode that flips the question to visibility. Only the bot parameter and the server-optionality (covered in schema) are left unexplained.

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 names the computed result (effective permissions after roles and channel overrides) rather than just restating the name, and the second sentence adds a distinct mode ("who can see this channel?"). It is easy to tell apart from set_permissions on the strength of "actually do ... after roles and channel overrides", though it never names a sibling explicitly.

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?

Usage is implied by two scenarios: checking a member/role's effective permissions, and channel-only visibility queries. There is no explicit statement of when not to use it (e.g. to change permissions, or to read raw role definitions), so the agent must infer the boundary from the sibling name set.

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