Skip to main content
Glama
Sign In
better-discord-mcp

better-discord-mcp

by Sys0xdbg
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

discord_request

Directly call any Discord REST API endpoint. Access all features, including those not covered by named tools.

Instructions

Advanced: call ANY Discord REST endpoint directly (covers every feature not wrapped by a named tool). path is relative, e.g. /guilds/{id}/templates.

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": {
      "path": "<path>"
    },
    "name": "discord_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNo
pathYesAPI path beginning with /, e.g. /channels/123/messages
queryNo
methodNoget
confirmNoSet true to actually perform this destructive action

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description must convey behavioral traits. It mentions the 'confirm' parameter for destructive actions but doesn't discuss authentication, rate limits, error responses, or idempotency. The behavior depends heavily on the endpoint, but the description could add more general warnings.

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 description is two sentences long and front-loaded with the purpose. It efficiently conveys the key point: it's a catch-all for endpoints not wrapped. Could be slightly more structured but is effective.

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?

The tool is complex as a raw API caller, and no output schema exists. The description doesn't explain return format, error handling, or how to use the 'confirm' parameter effectively. While the tool's purpose is clear, a more complete description would help agents handle responses and destructive actions safely.

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 40% (path and confirm have descriptions). The description adds meaning to 'path' by stating it's relative and giving an example. However, it doesn't clarify 'body', 'query', or 'method' beyond what schema shows. Given the low coverage, more description for these parameters would be beneficial.

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 clearly states it calls any Discord REST endpoint directly, covering features not wrapped by named tools. It uses specific verb 'call' and resource 'Discord REST endpoint' and distinguishes itself from the extensive list of sibling tools that wrap specific endpoints.

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?

The description implies when to use: for features not covered by named tools. It doesn't explicitly exclude using it when a named tool exists, but the context of sibling tools provides clear guidance. No prerequisites or error handling are mentioned, but the directive is clear enough.

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