discord-mcp

discord_get_user

Read-onlyIdempotent

Fetch a Discord user by ID to retrieve username, display name, avatar, banner, accent color, and bot status. Use it to resolve IDs from message authors, mentions, or poll voters.

Instructions

Fetch any Discord user by user ID: username, global name, avatar, banner, accent color and whether the account is a bot. Use it to resolve an ID taken from a message author, a mention or a poll voter; for the bot's own account use discord_get_my_user, and for guild data such as nickname, roles and join date use discord_get_guild_member (members toolset). Returns the user object. No special bot permissions. Read-only; safe to retry.

Input Schema

Name	Required	Description	Default
`user_id`	Yes	ID of the Discord user to fetch

Output Schema

Name	Required	Description	Default
`user`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.1.2Nov 4, 2026
- addedInput schema / properties / user_id / description
```
Added value: +"ID of the Discord user to fetch"
```
- removedOutput schema / properties / user / properties / global_name / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / user / properties / global_name / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- addedOutput schema / properties / user / properties / id / description
```
Added value: +"Discord snowflake ID as a numeric string"
```
First observedv0.1.0Nov 3, 2026

TDQS

A4.4/5.0

Behavior4/5

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

The statement that no special bot permissions are required adds useful operational context beyond the annotations. The read-only and retry guidance is consistent with the annotations but largely repeats their readOnlyHint and idempotentHint, so it adds little new information.

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 purpose is front-loaded, followed logically by use cases, alternatives, and operational notes. The return-value statement and final read-only/retry sentence duplicate structured metadata, making the description slightly longer than necessary for a one-parameter tool.

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 read operation with one fully documented parameter and an output schema, the description supplies the scope, practical usage contexts, alternatives, and permission requirements. No material information needed to select or invoke it correctly appears to be 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 100%, and the sole user_id parameter is already documented with its type and numeric pattern. The description adds modest provenance context by mentioning message authors, mentions, and poll voters, but no substantive parameter details beyond the schema.

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 specifies the operation, resource, lookup key, and returned profile fields, making the tool's scope immediately clear. It also distinguishes this lookup from both discord_get_my_user and guild-member retrieval.

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

Usage Guidelines5/5

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

Concrete use cases are provided: resolving IDs from message authors, mentions, and poll voters. Explicit alternatives are given for the bot's own account and for guild-specific data such as nicknames, roles, and join dates.

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