Discord MCP

by RestartFU

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools map cleanly to distinct Discord resources (messages, channels, roles, members, guilds). The main ambiguity is discord_request, which overlaps with nearly every other tool by design, but its generic nature is clearly described as a catch-all REST endpoint accessor.
Naming Consistency4/5
The vast majority of tools follow a consistent verb_noun pattern: read_messages, delete_message, list_roles, create_channel, get_guild, add_member_role. Minor deviations exist, such as discord_request as a standalone generic tool and get_current_user not matching the list/get style perfectly, but the overall pattern is predictable.
Tool Count4/5
32 tools is on the heavier side but justified for a Discord server integration covering messages, channels, members, roles, threads, invites, and reactions. The generic discord_request tool helps keep the count from being even larger, and every tool addresses a concrete Discord operation.
Completeness4/5
The surface covers core interaction and moderation workflows well: message lifecycle, channel lifecycle, role assignment, member updates, invites, threads, pins, reactions, and DMs. Notable gaps include no dedicated webhook/emoji/event tools, though discord_request explicitly covers those REST operations, so agents can work around the gap.
Average 3.4/5 across 32 of 32 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate a non-readonly, non-destructive create operation, and the description adds little beyond that. It does not disclose required permissions, what happens on failure, whether the role is immediately usable, or how the created role relates to other role operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the core purpose and does not waste tokens.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an opaque data object, no output schema, and no mention of return value or error behavior, the description is under-specified. An agent would still need external Discord API knowledge to know which role fields are supported and what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the compensation burden, but it does not explain the guild_id parameter or the structure of data. The phrase 'Discord role fields' loosely suggests that data contains role properties, but it is far too vague to clarify required or optional role field semantics.
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?
The description clearly identifies the action ('Create') and the resource ('a server role'), which is enough to distinguish from sibling tools like list_roles, add_member_role, and remove_member_role. However, it does not explicitly differentiate itself from any alternative or explain what 'Discord role fields' means in practice.
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?
No guidance is given about when to use this tool versus alternatives such as add_member_role or discord_request. It neither states prerequisites (e.g., required permissions) nor explains when this tool is the correct choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate that the tool is not read-only and not destructive, and the description confirms a mutating action. However, it does not describe potential side effects, errors, or constraints beyond starting a thread.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the core operation. It has no unnecessary filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not indicate what the tool returns or how to interpret the result. This leaves the agent with incomplete context for confirming success or handling the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no field-level documentation, and the description only vaguely mentions that data includes name, type, and optional auto_archive_duration. It does not explain the channel_id parameter or clarify the structure of the nested data object, which is fully open-ended.
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?
The description clearly states the primary action ('Start a thread') and names the resource (thread). It is distinct enough from general 'create' or 'send' actions, though it does not explicitly differentiate from sibling tools like create_channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_channel or send_message. There is no mention of prerequisites, ideal use cases, or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond what the annotations already provide: readOnlyHint is true, destructiveHint is false. 'Inspect' simply mirrors the read-only hint and does not disclose additional behaviors such as what happens for invalid guild IDs, rate limits, or field scope.
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 only four words and is front-loaded with the core action. It is efficient and free of filler, though it sacrifices informative depth for brevity.
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 simple one-parameter getter with read-only annotations, the description is minimally adequate. However, with no output schema and no mention of return details, error behavior, or relationship to list_guilds, an agent gets only an incomplete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain guild_id or its format. While the schema's title 'Guild Id' and pattern are somewhat self-explanatory, the description fails to add meaningful parameter semantics beyond that.
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?
The description 'Inspect server details' uses a specific verb and resource, clearly indicating a read operation for a single guild/server. The name get_guild and the required guild_id parameter distinguish it from list_guilds and other tools, though it does not explicitly say 'by guild_id'.
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?
The description gives no guidance on when to use this tool versus alternatives like list_guilds, get_channel, or get_member. It only implies use when server details are needed, with no exclusions or explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint, openWorldHint, and destructiveHint false. The description only repeats the read-only nature via the verb 'List' without adding any further behavioral context (e.g., permissions required, pagination, or side effects). Since it adds no new information beyond the annotations, the score is low.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is appropriately sized. The verb 'List' is front-loaded, immediately conveying the action. There is no irrelevant or redundant wording.
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 description is minimally adequate for a simple tool, but lacks contextual details such as what constitutes a channel, whether the operation is scoped, or how it differs from fetching a single channel. It does not mention any edge cases or alternatives, so the completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'guild_id' with no description, and the tool description does not explain it. The parameter name suggests it is the server identifier, but the description does not explicitly connect it to the action. With 0% schema coverage and no compensatory explanation, the meaning is not enhanced.
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 the verb 'List' and the resource 'channels', identifying the tool's purpose. It distinguishes itself from sibling tools like 'get_channel' (singular) and 'create_channel' by focusing on listing all channels in a server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used to retrieve all channels, nor does it contrast with 'get_channel' or other channel-related tools. There is no explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already signals the destructive nature, and the description's verb 'delete' reinforces this without contradiction. The description adds 'where permitted,' which subtly hints at permission checks but does not elaborate on side effects, permanence, or failure modes. Since annotations cover the primary risk, this is adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no redundant words. It immediately states the action and object, making it highly scannable. No unnecessary details or filler are present.
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?
Given the simplicity of the operation, the description is minimally sufficient but lacks context about potential errors, return values, or permission requirements beyond the vague 'where permitted.' It does not explain what happens if the message does not exist or if the user lacks permission. For a destructive action, a bit more context would improve completeness, but the core function is conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for channel_id or message_id, and the tool description does not explain their meaning or relationship. Although the parameter names are intuitive, the description adds no value beyond the schema. There is no mention of required formats, constraints, or how the parameters interact.
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 the action (delete) and the target (a message), making the purpose unambiguous. It is distinguished from sibling tools like delete_channel by specifying 'message' as the resource. The phrase 'where permitted' adds a minor caveat but does not obscure the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as edit_message or delete_channel. It does not mention prerequisites, edge cases, or situations where deletion might be disallowed. There is no explicit indication of when this tool is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds one valuable behavioral detail: a 202 indexing response is returned as data and should be retried later. This is useful beyond the annotations, though the description does not address pagination behavior or output shape. With annotations in place, this is a solid but not exceptional disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The primary purpose is front-loaded, and the edge-case retry note is placed after, which is the right ordering. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter tool with no output schema, this description is incomplete. It does not explain what the result looks like, what content means as a search query, that guild_id is required, or how limit/offset pagination behaves. The indexing note is helpful, but an agent would still lack essential invocation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries a heavy burden for explaining parameters. It does mention optional channel and author filters, which maps to channel_id and author_id, but it entirely omits the required guild_id and content parameters and does not explain limit or offset semantics. This is only partial compensation for the schema's silence.
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?
The description states a clear verb and resource: 'Search server messages', which immediately distinguishes it from reading or editing messages. It also identifies optional channel and author filters, giving the agent a concrete sense of scope. However, it does not explicitly differentiate itself from siblings like read_messages, so it stops short of a 5.
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?
The description gives no explicit guidance on when to prefer search_messages over read_messages, get_message, or other sibling tools. It implies a search use case due to the verb, but there is no stated when-to-use, when-not-to-use, or alternative routing. The indexing note is operational guidance, not usage-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, which already convey that changes are made. The description adds the word 'update', which aligns with those annotations but does not provide additional behavioral context, such as side effects or whether existing data is replaced or merged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and directly to the point, containing no unnecessary words or repetition. It clearly communicates the essence of the tool in a single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is missing crucial context about the data parameter's structure and allowed fields. Without this, an agent would not know how to construct a valid request, and the behavior of the tool when updating permissions or metadata is not explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The channel_id parameter is well-defined as a string, but the data parameter is an open object with no specified properties. The description mentions 'Discord fields' but does not enumerate them or explain what fields are accepted, leaving the parameter's meaning vague and under-specified.
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?
The description clearly states the tool updates a channel with specific examples (name, topic, permissions, thread metadata) and uses the verb 'update', making its purpose explicit. However, it does not explicitly differentiate from sibling tools like 'create_channel' or 'update_member', though the resource is clear from the channel_id parameter.
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?
The description does not provide any guidance on when to use this tool versus alternatives. Sibling tools like 'create_channel' or 'update_member' are not referenced, and there is no indication of prerequisites or conditions under which this tool should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only and non-destructive nature is covered by annotations. The description adds no extra behavioral details, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words or repetition.
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 description covers the basic action and the schema identifies the required parameter, but it lacks details about the return format or any additional context needed for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines guild_id but provides no description. The description does not explain what the parameter represents or how it is used, relying on the parameter name's self-explanatory nature.
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?
The description clearly states the tool lists server invites, which distinguishes it from invite creation. The phrase 'where permitted' adds a slight condition but does not obscure the core purpose.
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?
No explicit guidance is provided about when to use this tool over siblings like 'create_invite' or other list operations. The description relies on the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description's 'List' matches this, but adds no additional behavioral context such as rate limits or response size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and to the point, using a clear verb-object structure with no unnecessary words. It is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided and the description does not indicate what information is returned (e.g., role names, permissions, IDs). The description is too sparse to give an agent sufficient context for a complete interaction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name 'guild_id' with no description, and the description does not explain its purpose, format, or constraints. With 0% schema coverage and no supplementary explanation, the semantics are entirely missing.
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 the verb 'List' and the object 'server roles and permissions', making its purpose specific and distinct from role-modifying tools like create_role.
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?
No guidance is provided on when to use this tool versus alternatives such as list_guilds or get_guild. The description does not mention conditions or scenarios that would make this tool the preferred choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutating but non-destructive action (readOnlyHint=false, destructiveHint=false), and the description adds little beyond 'its channel'. It does not disclose permissions, whether pinning is idempotent, failure scenarios, or side effects. Thus it provides no behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one concise sentence with the verb front-loaded and no filler words. It is appropriately minimal for a straightforward action, earning maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two required parameters and no output schema, the description omits how to obtain the IDs, what success looks like, and references to related tools like list_pins or unpin_message. It does not provide enough surrounding context to guarantee correct invocation in varied workflows. Thus the definition is incomplete despite its clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description must carry parameter meaning, but it only refers to 'a message' and 'its channel' without mapping to channel_id and message_id or explaining their relationship. 'Its channel' weakly implies the message's home channel, but does not clarify ID formats or constraints. This is insufficient compensation for the schema gap.
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?
Description uses a specific verb 'Pin' with resource 'a message' and location 'in its channel', making the operation unambiguous. It is distinguishable from siblings like unpin_message and list_pins by the action word. Even with a null title, an agent can infer exactly what the tool does.
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?
The description offers no explicit when-to-use guidance or alternatives. It does not mention unpin_message or list_pins for related workflows, nor preconditions such as message existence or permissions. The only usage implication is the imperative phrasing itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag the operation as destructive/readOnlyHint=false, and the description adds no context beyond the removal itself. It does not mention permissions, role hierarchy, or effects when the role is absent, so it provides no behavioral detail beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler or redundant wording. Every word contributes to the meaning.
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?
Adequate for a simple three-ID tool with destructive annotations, but it has clear gaps: no expected return/response, no failure conditions, and no mention of Discord role hierarchy or bot permissions for this destructive action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly explain role_id, user_id, and guild_id. It loosely maps 'server' to guild_id and 'member' to user_id, but it leaves parameter meaning and value semantics to the schema names and patterns.
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?
The description states a specific verb and resource: removing a server role from a member. It is clear and easily distinguished from siblings like add_member_role, though it does not explicitly name that alternative.
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 by the phrasing: use this when a role should be removed from a member. There is no explicit when-to-use guidance or mention of alternatives such as add_member_role or update_member.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate a destructive write operation (readOnlyHint false, destructiveHint true). The description adds some specificity by naming the modifiable fields, but does not disclose potential side effects such as removing roles or resetting timeouts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the verb and target. It is concise and free of unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool involves a nested 'data' object, yet the description does not explain its structure or permissible values. Without output schema or parameter details, the description is insufficient for correct usage, especially given the destructive nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no details about the parameters. The schema has three required fields (guild_id, user_id, data) with zero description coverage. The phrase 'using Discord fields' does not explain what 'data' should contain, so the agent cannot construct a valid request.
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 the action ('Modify') and the resource ('member'), and explicitly lists the affected fields (nickname, roles, timeout, mute, voice channel). This distinguishes it from sibling tools like add_member_role or remove_member_role.
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?
No guidance is provided on when to use this tool versus alternatives like add_member_role or remove_member_role. It does not mention whether this is for combined updates or specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'subject to Discord permissions,' which hints at authorization requirements, but it does not explain side effects such as creating a new DM channel if one does not exist, nor does it mention rate limits or failure conditions. The openWorldHint suggests side effects, but the description leaves those details vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It conveys the core action, target, and a relevant constraint without any unnecessary words or repetition.
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 description is adequate for a simple tool, but it omits important context such as what the tool returns, whether an existing DM channel is reused, and any permission-related failure modes. Given no output schema is provided, a bit more detail would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a parameter name and pattern, with no description. The tool description says 'with a user' but does not explicitly state that recipient_id is the user's ID or how it should be formatted. The parameter is somewhat self-explanatory, but the description does not fully compensate for the missing schema description.
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 the action: opening a direct-message channel with a user. The phrase 'with a user' distinguishes this from general channel creation tools like create_channel, making the purpose unambiguous.
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?
The description gives no explicit guidance about when to use this tool versus alternatives. Although 'direct-message' implies the intended use case, it does not mention when not to use it or contrast it with similar tools such as create_channel or send_message.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-destructive operation. The description adds little behavioral context beyond that: it does not mention side effects, permission requirements, whether the invite is immediately active, or any rate-limit concerns. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tight sentence with the core action front-loaded and no filler. Every clause adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and an open-ended 'data' object, the description is too thin to fully inform an agent. It omits return values, required permission context, valid values for max_age/max_uses, and what 'unique' controls. The nested object with additionalProperties true makes this ambiguity more impactful.
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?
The input schema gives no descriptions for either parameter, and schema description coverage is 0%, so the description must compensate. It does clarify that the nested 'data' object may include max_age, max_uses, and unique, but it leaves their types, units, and exact semantics undefined. channel_id is still explained only by the tool name.
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 states a specific action and resource: 'Create a channel invite'. It clearly differs from sibling tools like list_invites, create_channel, and send_message by naming the exact object being created.
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?
No guidance is given about when this tool should be used instead of alternatives, nor does it mention prerequisites like required Discord permissions. The agent must infer usage entirely from the tool name and the single-line description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already signals that this is a mutation. The description adds no extra behavioral detail (e.g., permanent overwrite of content) but does not contradict the annotation either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the verb and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits important context such as the need for the message to exist, the role of channel_id/message_id in locating it, and any potential side effects beyond editing. It relies entirely on the parameter names and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions for content, channel_id, or message_id). The description does not explain the purpose of these parameters, though their names are somewhat self-explanatory.
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 verb 'Edit' is specific and the resource 'existing message' is clearly defined. It distinguishes from send (creating new) and delete (removing) without ambiguity.
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?
No guidance is provided on when to use this tool versus alternatives like delete_message or send_message. The phrase 'where the credential permits it' only hints at permission constraints, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, openWorldHint, and destructiveHint. The description's 'Inspect' is consistent with these but adds no extra behavioral detail, so a neutral score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy or filler. It is well-structured and immediately understandable.
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?
Given the simplicity of the operation, the description is minimally acceptable, but it does not mention what fields a user profile contains, how errors are reported, or any other output details. Since there is no output schema, a bit more context would have been helpful.
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?
The schema fully covers the single user_id parameter with a type and pattern, meeting the high coverage baseline. The description gives no additional meaning beyond implying that the ID identifies the user whose profile is inspected.
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 the action (inspect) and the resource (user profile), immediately distinguishing it from sibling tools like get_member or get_channel. Even without explicit sibling comparisons, the noun phrase is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_member or get_guild. The description gives no context about typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds no additional behavioral context beyond what is already in the annotations, so it neither enhances nor contradicts the declared behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no filler. It conveys the core purpose and the key pagination hint efficiently, earning full marks for economy of expression.
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?
Given the simple nature of a list operation and the presence of pagination parameters, the description provides minimal context. It lacks any indication of response shape, ordering, or the effect of 'before' versus 'after,' so an agent may need to infer behavior from the schema or other sources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it only minimally explains the 'after' parameter for pagination. The 'limit' and 'before' parameters remain unexplained, leaving significant ambiguity for an agent invoking the tool.
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?
The description clearly states the action ('List') and resource ('accessible servers' = guilds), distinguishing it from singular fetch tools like get_guild or other list tools like list_channels. It does not explicitly name a sibling alternative, but the verb + resource makes the purpose unambiguous.
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?
The description provides an implicit usage hint ('pass the last ID as after to paginate') but does not explain the 'before' or 'limit' parameters, nor does it contrast with alternative tools for retrieving guilds. The guidance is partial and leaves gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate that this is not read-only and not destructive, and the description aligns with that by stating it creates a channel. However, it adds little beyond that: no mention of required permissions, rate limits, server limits, or side effects. The description does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It leads with the action and resource, then gives the most important payload contents, making it easy for an agent to parse quickly.
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 tool, the description is minimally viable: it identifies the resource, the target guild via guild_id, and hints at the payload shape. However, it omits cross-references to update_channel/delete_channel, expected return value, and permission requirements, leaving notable gaps for an agent unfamiliar with Discord's API.
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?
The schema has 0% description coverage and data is an unconstrained object, so the description must compensate. It does add useful meaning by listing 'name' and 'optional type or permission_overwrites', but it leaves gaps around the required fields inside data, the format of type, and the meaning of guild_id beyond its name.
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 states the exact action and resource: 'Create a server channel', which clearly distinguishes it from sibling tools like update_channel, delete_channel, and create_thread. It also names the primary data fields, giving an agent a concrete idea of what the tool produces.
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?
No guidance is given about when to use this tool versus alternatives such as update_channel, create_thread, or delete_channel. There is no mention of permission prerequisites, Discord server context, or situations where channel creation would be appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds no additional behavioral context such as permission requirements, side effects, or reversibility, so it doesn't go beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence with no filler. It is appropriately front-loaded and avoids unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The operation is simple with only two self-explanatory parameters, and annotations cover the destructive nature. However, with 0% schema coverage, a brief clarification of the parameters or the fact that this only removes the pin without deleting the message would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain that channel_id identifies the channel containing the message or that message_id is the pin to remove. The agent must rely on parameter names and domain knowledge.
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 uses a specific verb 'Remove' and a specific resource 'message pin', clearly stating the tool's function. It also differentiates from sibling tools like pin_message and list_pins without needing to open the schema.
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?
No guidance is provided about when to use this tool versus alternatives such as delete_message or edit_message. The intended context is only implied by the tool name, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that this is not read-only and not destructive, and the description's 'assign' action aligns with those expectations. However, the description adds no behavioral context beyond the annotations, such as permission requirements, error cases, or side effects like role reassignment. It is consistent but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the operation. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, the required parameters are clearly named, and annotations cover the safety profile, the description provides sufficient context for an agent to understand the operation. It could be improved by mentioning role hierarchy or permission requirements, but these are not essential for basic invocation.
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 description coverage is 0%, so the description must compensate for parameter meaning. It partially does by mapping 'server role' and 'member' to the conceptual roles of role_id, guild_id, and user_id. However, it does not explicitly define each parameter or clarify constraints like guild membership, giving only implicit semantic context.
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 uses a specific verb and resource: 'Assign a server role to a member.' It clearly identifies the primary action and entity, distinguishing it from sibling tools like remove_member_role and list_roles. It is concise, unambiguous, and not a tautology.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention remove_member_role or any condition for choosing add_member_role. The implied use case is easy to infer from the verb, but there is no explicit context or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-destructive operation. The description adds useful behavioral context about supported emoji formats and automatic URL encoding. However, it does not disclose potential side effects such as duplicate reactions or what happens with invalid emoji, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundant wording. It conveys the core action, accepted formats, and a key technical detail (URL encoding) efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter mutation with no output schema, the description is largely complete. It covers the one non-obvious detail (emoji format) and encoding behavior. It could mention idempotency or duplicate behavior, but the essential information for calling the tool correctly is present.
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?
With 0% schema description coverage, the description must compensate. It does clarify the emoji parameter by specifying Unicode emoji or custom name:id format and automatic URL encoding. It provides no added meaning for channel_id or message_id, though their names and numeric patterns make their purpose fairly self-evident.
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?
The description states a specific action ('React') with the resource being a message, implied through the message_id parameter. It clearly identifies the emoji input format, making the tool's function understandable. It does not explicitly differentiate from siblings like send_message, but the verb is specific enough.
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?
The description implies the tool is for adding reactions to messages, but it gives no explicit guidance on when to choose this over alternatives, nor any exclusions or prerequisites. The context is clear enough for a straightforward mutation, but no alternatives or when-not-to-use scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only behavior, but the description does not specify the exact output format or whether the response includes the full member object, roles, or both.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description leaves significant ambiguity about the response structure, which is critical for an AI agent to use the tool correctly, especially given no output schema.
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?
Parameter names and patterns are given in the schema, but the description adds no extra clarification about their roles (e.g., that user_id is the member's ID within the guild).
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 the action (inspect) and the resource (a server member and their roles), distinguishing it from sibling tools like list_members or get_user.
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?
The description implies use when needing member details, but does not explicitly contrast with related tools or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the singular granularity but does not describe other behavioral aspects such as error responses, missing-message handling, or return format. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three words with no filler, front-loaded, and every word contributes meaning. It is concise without sacrificing core clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/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 strong read-only annotations and a clear required-parameter schema, the description is mostly complete. It could be improved by mentioning that a single message object is returned and by distinguishing usage from read_messages, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention channel_id or message_id at all. The parameter names are self-explanatory, but the description fails to compensate for the lack of schema descriptions or clarify how the IDs relate to the operation.
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 'Read one message' uses a specific verb and resource, clearly identifying a single-message retrieval operation. It distinguishes itself from plural/sibling tools like read_messages by emphasizing 'one' message.
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 context is implied: use this tool when you need a single message identified by channel and message IDs. However, it does not explicitly state when to prefer read_messages or search_messages instead, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the destructive action, and annotations already mark it as destructive and not read-only. It does not add extra context like irreversibility, cascading deletions, or permission requirements beyond what the annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words, directly conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive action, the description provides enough context to understand the tool's core function. It does not mention returns or errors, but no output schema is present and the purpose is clear.
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?
The only parameter, channel_id, is not formally described in the schema, and the description only indirectly implies it identifies the channel or DM to act on. The parameter name is clear, but no additional constraints or clarifications are provided.
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?
Clearly states the action ('Delete'/'close') and the target resource ('a channel' or 'a DM'), making its purpose unambiguous and distinguishing it from sibling tools like delete_message.
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?
The description implies when to use it (whenever a channel or DM needs to be removed) but does not explicitly mention alternatives, prerequisites, or scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds the specific scope of what is inspected (metadata and permission overwrites). It does not contradict the annotations, and this incremental context is enough for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; every word carries content. The resource and the specific details being inspected are immediately visible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with safety annotations and no output schema, the description conveys the essential behavior and scope. It says what will be returned (metadata, permission overwrites) and is complete enough for selection and invocation.
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?
The schema has 0% description coverage, and the description does not explicitly explain the channel_id parameter. However, the single parameter is self-evident from its name and pattern, and the description's focus on 'channel' reinforces its role, so no meaningful gap exists.
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 uses a specific verb ('Inspect') with a specific resource ('channel metadata and permission overwrites'), and the singular 'channel' clearly distinguishes it from siblings like list_channels and get_guild. It tells the agent exactly what will be retrieved.
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?
The word 'Inspect' implies use when a read-only view of a single channel's metadata or permission overwrites is needed, but there is no explicit when-or-when-not guidance or reference to alternatives. The context is inferable from the purpose statement, but exclusions and sibling comparisons are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, non-destructive, and open-world, so the bar is lower. The description adds useful behavioral context by specifying that results are filtered by the active status and by what the credential can access. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word contributes to the meaning, and the main action is immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only list tool, the description covers the essential scope and access filtering, and the annotations cover safety. It does not describe output structure or pagination, but there is no output schema and the resource being listed is clear from the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for documenting the single guild_id parameter. It only indirectly ties guild_id to 'server' and does not explicitly explain the parameter's role, format, or source; the property name and pattern carry most of the meaning.
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 states a specific verb ('List'), a specific resource ('active server threads'), and a clear scope ('accessible to this credential'). It is easily distinguished from sibling tools like create_thread or list_channels, which target different resources or actions.
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?
The intended use is implied: enumerate active threads in a guild using guild_id. However, the description does not explicitly say when to prefer this tool over alternatives such as list_channels or search_messages, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly and non-destructive behavior. The description adds meaningful behavioral context by disclosing the requirement for intents and the pagination mechanism, which are not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, focused sentences with no redundant information. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple read-only listing tool, covering the intent caveat and pagination. However, it omits details about the output format and error conditions, which would be helpful for full self-sufficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only partially explains the 'after' parameter via the pagination hint. The 'limit' parameter's role and the 'guild_id' requirement are not described, leaving the agent to infer their semantics from the schema alone.
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 states the verb 'List' and the resource 'server members' clearly, leaving no ambiguity about what the tool does. It is specific enough to distinguish from siblings like list_guilds or list_roles.
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?
The description mentions 'subject to required intents' and gives a pagination hint, but it does not explicitly state when to prefer this tool over alternatives such as get_member or list_roles. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral caveats: pagination via the before parameter and that Discord may omit message content when credentials lack access or intent. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense. Both sentences add value: the first states the operation and key pagination pattern, the second states a constraint and a content-omission caveat. No wasted words.
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 five-parameter tool with no output schema, the description covers the read-only nature, pagination, parameter exclusivity, and a data-completeness caveat. However, it does not describe the expected return shape or the detailed semantics of after and around, leaving moderate gaps for an agent.
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 description coverage is 0%, so the description must carry parameter meaning. It clarifies before for pagination and imposes mutual exclusivity among before, after, and around, but it leaves after, around, limit, and channel_id semantics mostly to inference from parameter names.
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?
The description clearly states a concrete action and resource: reading channel or thread history. It is distinct from single-message or search tools, though it does not explicitly name a sibling alternative such as search_messages.
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 gives concrete pagination guidance ('Use the oldest message ID as before for older pages') and explicitly restricts parameter combinations ('Only one of before, after, around may be supplied'). It does not explain when to prefer this over search_messages or get_message, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false. The description's 'Inspect' matches this perfectly, and it does not contradict or omit any side-effect information relevant for a simple read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words or details. It is optimally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless, read-only tool, the description provides sufficient context. It explains exactly what action is performed and on what resource, and no further explanation is needed given the tool's trivial nature.
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?
The tool has no parameters, so the schema fully covers the input requirements. The description does not add any additional parameter semantics because none exist, which is appropriate and meets the baseline.
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 uses a specific verb ('Inspect') and resource ('authenticated Discord account'), making the tool's purpose unmistakable. It clearly distinguishes itself from sibling tools that operate on guilds, channels, messages, or roles.
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 clearly implies when to use this tool (to retrieve information about the currently authenticated user) and no explicit alternative is needed because no sibling tool serves the same purpose. It could have explicitly stated 'use this instead of get_user for the authenticated account,' but it is still evident from the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only and non-destructive nature. The description adds value by disclosing that only the first page is returned and that pagination requires discord_request, which is not visible in the annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that states the action first and the pagination caveat second. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one obvious parameter, the description covers the key behavioral nuance: first page only and how to paginate. It does not describe the return format or limits, but the lack of an output schema and the simple nature keep this from being a major gap.
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 description coverage is 0%, but there is only one parameter, channel_id, with a clear title and pattern. The description does not explicitly explain the parameter, though 'pinned messages' combined with channel_id makes the meaning inferable. It is adequate but not enriching.
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 uses a specific verb and resource: 'List the first page of pinned messages.' It clearly distinguishes list_pins from mutation siblings like pin_message and unpin_message, and from general read_messages.
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 explicitly directs the agent to use discord_request with 'before' when pagination is needed, which is a clear alternative for a concrete condition. It does not explicitly state when not to use list_pins beyond the first-page scope, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds transparency beyond the annotations by noting 'Total upload limit is 10 MiB' and 'Discord permissions and endpoint limits still apply.' These are important behavioral constraints not captured in the annotations. It does not explicitly warn about destructive actions, but the annotations already indicate destructiveHint=true, and the generic 'Call any endpoint' clearly implies possible destructive behavior.
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 reasonably concise, with a clear opening sentence and a compact list of covered categories. The file example is a bit verbose but helpful. The overall structure flows logically from purpose to usage to limits, though the repetition of 'REST operations' is slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's generic nature, the description covers essential context: what it does, how to structure requests, file upload constraints, and that Discord's own permissions/limits apply. It does not address error handling or authentication, but those are likely implied by the platform context. The absence of an output schema is acceptable for a generic endpoint caller.
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?
The schema provides no descriptions for parameters (0% coverage), so the description adds meaning by explaining that 'path' and 'query' are supplied separately, and it gives a concrete example for the 'files' parameter structure. However, it does not elaborate on the 'body', 'method', or 'reason' parameters, leaving some ambiguity for those fields.
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 the tool's purpose: 'Call any Discord v10 REST endpoint.' This is a specific verb and resource, and it distinguishes itself from the many specialized sibling tools (e.g., send_message, delete_message) by acting as a generic REST caller. The examples like '/guilds/123/roles' further clarify what it does.
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 provides usage guidance by listing covered areas (permissions, roles, moderation, invites, webhooks, emojis, scheduled events, threads, polls, and other REST operations). This implies that the tool is for operations not covered by dedicated siblings, though it does not name a specific alternative. The instruction 'Supply API-relative path and query separately' also gives practical usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses that mentions don't ping by default and that explicit mentions require discord_request. This is useful non-obvious behavior. It does not cover response shape or permission failures, but those are less critical for a simple send tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The core action is first, followed by a naming/ping caveat, then a focused pointer to the alternative tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a small 3-parameter tool with no output schema, the description plus schema provides enough to select and invoke it correctly. Missing details are a return-value description and explicit channel_id semantics, but neither blocks correct use given the self-explanatory parameter names.
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 property descriptions are absent, so the description must carry the semantics. 'Send a message or reply' maps content and reply_to, and the discord_request boundary implies content is plain text rather than attachments/embeds. However, channel_id is only inferred from the property name/title, and reply_to's behavior is not elaborated.
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 uses a specific action verb ('send') and resource ('message or reply'), and immediately clarifies an unexpected behavior ('Mentions do not ping by default'). This clearly distinguishes it from sibling discord_request while covering the core function.
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?
The second sentence explicitly routes alternative usage: 'Use discord_request for attachments, embeds, polls, components, or explicit mentions.' This gives concrete when-not-to-use guidance and names the sibling tool, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Discord MCP MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![Discord MCP MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/RestartFU/discord-mcp/badges/card.svg)](https://glama.ai/mcp/servers/RestartFU/discord-mcp)

Score Badge

Copy to your README.md:

[![Discord MCP MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/RestartFU/discord-mcp/badges/score.svg)](https://glama.ai/mcp/servers/RestartFU/discord-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/RestartFU/discord-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server