Discover Discord API operations and retrieve exact route IDs, request body schemas, and query fields; call without a group for a catalog summary or with group and action for detailed schema.
Discover operations and exact required route IDs, body schema and query fields. With no group returns the catalog summary; group+action returns a detailed schema.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | ||
| action | No |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior. The description adds useful behavioral detail by specifying that no group yields a catalog summary while group+action yields a detailed schema, though it does not discuss auth or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The core discovery purpose is front-loaded, followed immediately by the conditional return behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a help/discovery tool with no output schema, the description gives only a high-level distinction between catalog summary and detailed schema. It leaves unresolved what happens with group-only/action-only calls and what the returned schema actually contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It explains the no-group and group+action cases, but does not clarify group-only behavior, action-only behavior, action format, or how action relates to the group enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ("Discover") and resource (operations, route IDs, body schema, query fields) and clearly frames this as a catalog/help tool. It does not explicitly contrast itself with the many sibling operation tools, but the name and wording make its meta purpose recognizable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states two calling modes: no group returns the catalog summary, and group+action returns a detailed schema. However, it does not explicitly say when to choose this tool over a sibling tool or that it should be used before invoking a specific operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.