discord-server-mcp

use_bot

Select the default Discord bot for requests that do not name a server; named servers still route to the correct bot automatically.

Instructions

Choose the default bot (used when a request does not name a server). Tools still pick the right bot automatically when a server is named.

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": {
      "bot": "<bot>"
    },
    "name": "use_bot"
  }
}

Input Schema

Name	Required	Description	Default
`bot`	Yes	Bot name or id from list_bots
`dry_run`	No	Show the requests that would be made without changing anything

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 12, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations only declare readOnlyHint=false, so the description must carry the rest. It does add real value by explaining the fallback semantics of the default and that automatic selection still applies to server-scoped calls. It does not say whether the choice is persisted, scoped per session/workspace, or what the dry_run parameter changes about the outcome.

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?

Two short sentences with no filler, and the core action is front-loaded before the fallback explanation. Slightly compressed wording ('a request does not name a server') leans on the reader sharing context about what a server is here.

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 two-parameter mutation tool with no output schema, the description covers purpose and fallback scope but omits persistence, interaction with sibling bot-selection tools, and the effect of dry_run. Enough to call it, not enough to predict its consequences.

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 parameters are already documented in the schema. The description adds meaning to 'bot' only implicitly via 'default bot', and says nothing about dry_run beyond what the schema states. Baseline 3 is appropriate.

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?

States a specific verb and resource: 'Choose the default bot'. The parenthetical defines what 'default' means (the bot used when no server is named), which distinguishes it from per-server siblings like set_server_bot. It stops short of naming those siblings 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 rather than stated: you set a default so requests without a server name resolve to some bot, and you don't need to call it when a server is named because tools auto-select. There is no explicit 'use this when / use set_server_bot instead when' routing, so the agent must infer the boundary.

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