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 welcome screen

get_welcome_screen
Read-only

Retrieve a Discord server's welcome screen to review its onboarding message and channel setup. Specify a guild name or ID, or omit it to use the default guild.

Instructions

The Community welcome screen, when the server has one.

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": "get_welcome_screen"
  }
}

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.4.2
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed1 schema field changedv1.3.0
    • removedInput schema / additionalProperties
      Removed value: -false
  3. First observedv1.0.2

TDQS

B3.1/5.0
Behavior3/5

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

The readOnlyHint annotation already establishes the safe-read profile, so the description's main contribution is disclosing that the resource is optional and may be absent — useful context an agent would otherwise miss. It stops short of describing the returned fields or any failure behavior when no welcome screen exists.

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?

One short sentence with no filler, and the existence caveat is included rather than buried. It is a noun phrase rather than a complete clause, which slightly weakens front-loaded clarity about what action is taken.

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 zero-required-parameter read with full schema coverage and no output schema, the definition covers the bare essentials plus the optionality caveat. It remains thin on what a welcome screen returns and on the default-guild behavior implied by the schema, leaving the agent to infer those from structured fields.

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?

With a single optional parameter at 100% schema description coverage, the schema already fully documents the guild name-or-ID and the default-guild fallback. The description's mention of 'the server' loosely aligns with that parameter, so no additional semantics are needed or missing.

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

Purpose3/5

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

The fragment 'The Community welcome screen, when the server has one' identifies the resource but never states a verb, relying on the tool name get_welcome_screen to convey retrieval. It also gives no signal distinguishing it from the sibling update_welcome_screen or other get_* tools beyond the resource name itself.

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 explicit when-to-use guidance and no named alternative. The clause 'when the server has one' hints at a precondition (the server may lack a welcome screen) but does not instruct the agent what to do in that case or when to prefer this over other inspection tools.

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