Skip to main content
Glama
Sign In
Discord MCP - Discord server management MCP for AI agents

Discord MCP - Discord server management MCP for AI agents

by OrygnsCode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get member access

get_member_access
Read-only

Shows what a Discord member can access across a server: server-wide powers, visible channels, posting/joining rights, extra channel permissions, and inaccessible channel count. Read-only.

Instructions

What one member can reach across the server: their server-wide powers, every channel they can see (and whether they can post or join there), channels where they hold extra powers, and how many channels are closed to them. Read only. For why one permission is or is not there, use explain_permissions.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "member": "<member>"
    },
    "name": "get_member_access"
  }
}

Input Schema

NameRequiredDescriptionDefault
guildNoGuild (server) name or ID. Omit to use the default guild.
memberYesMember name or user ID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.2

TDQS

A4/5.0
Behavior3/5

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

The readOnlyHint annotation already declares the safety profile, and 'Read only' merely restates it. The valuable addition is the disclosure of what the response contains (visible channels with post/join status, extra-power channels, closed-channel count), but there is no mention of scale limits, pagination, or behavior on large servers.

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 scope enumeration is front-loaded in a single dense sentence, followed by a short safety note and a pointer to the sibling tool. No sentence is wasted and nothing is buried.

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?

With no output schema, the description does the work of describing the return shape, which it does well for a two-parameter read tool. The remaining gap is scale behavior for servers with many channels, which an agent might need before calling.

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 100%, so both 'member' and 'guild' are already documented in the schema, including the default-guild behavior. The description adds nothing about accepted formats (name vs. ID) or resolution ambiguity, 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?

The description gives a specific verb-and-resource framing ('what one member can reach across the server') and then enumerates the exact payload: server-wide powers, visible channels with post/join flags, channels with extra powers, and a count of inaccessible channels. This is far more concrete than the title and clearly distinguishes it from a plain member lookup.

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 explicitly routes the 'why' question to explain_permissions, which is the key disambiguation an agent needs against a very similar sibling. It does not, however, contrast itself with get_member_permissions or get_channel_access, so the agent must infer that this is the member-centric aggregate view.

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

Deploy Server

Other Tools