Discord MCP Server
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity, as they target specific Discord actions like friend management, message handling, channel operations, and presence updates. The descriptions clearly differentiate between similar actions, such as discord_add_friend vs discord_remove_friend or discord_send_message vs discord_edit_message, ensuring agents can easily select the correct tool.
Naming Consistency5/5All tool names follow a consistent verb_noun pattern with the prefix 'discord_', such as discord_add_friend, discord_edit_message, and discord_get_channel. This uniformity makes the tools predictable and easy to understand, with no deviations in naming conventions across the set.
Tool Count5/5With 19 tools, the server is well-scoped for Discord interactions, covering a comprehensive range of actions from messaging and reactions to friend management and presence updates. Each tool earns its place by addressing specific needs without redundancy, making the count appropriate for the domain.
Completeness5/5The tool set provides complete coverage for Discord operations, including CRUD actions for messages (send, edit, delete, get), friends (add, remove, list), channels (get, DM creation), and presence (update, clear). There are no obvious gaps, as it supports core workflows like attachment handling, message history, and search, ensuring agents can perform all essential tasks.
Average 3/5 across 19 of 19 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on
- 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.jsonto 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?
With no annotations provided, the description carries full burden but only states the basic action without behavioral details. It doesn't disclose permissions required, rate limits, whether reactions are reversible, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately understandable without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks behavioral context (e.g., permissions, side effects) and doesn't compensate for the absence of structured fields, leaving significant gaps in understanding how the tool operates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters like 'channelId' and 'emoji'. The description adds no additional meaning beyond the action itself, such as explaining emoji formats or ID sources. Baseline 3 is appropriate when schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a reaction') and target ('to a message'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'discord_remove_reaction' or 'discord_edit_message', which would require explicit comparison to achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There are no mentions of prerequisites (e.g., needing message access), exclusions, or comparisons to siblings like 'discord_remove_reaction' or 'discord_send_message', leaving usage context entirely implicit.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool can 'create or get existing' a DM, implying idempotent behavior (no duplicate channels), but doesn't cover critical aspects like permissions needed, rate limits, error conditions (e.g., invalid user IDs), or what happens if the user is blocked. For a mutation tool (creating channels) with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality ('Create or get existing DM channel with a user'). There is no wasted verbiage or redundancy, making it easy to parse quickly while conveying the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with potential side effects), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return value (e.g., channel ID or object), error handling, or behavioral nuances like idempotency. For a tool that modifies state, more detail is needed to ensure safe and correct usage by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'userId' clearly documented, so the baseline is 3. The description adds no additional parameter context beyond what the schema provides (e.g., format examples, validation rules, or how user IDs are obtained). It merely implies the parameter's purpose without enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create or get') and resource ('DM channel with a user'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'discord_get_dm_channels' (which likely lists multiple DMs) or 'discord_get_channel' (which might handle other channel types), leaving some ambiguity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites (e.g., whether the user must be a friend), exclusions, or comparisons to siblings like 'discord_get_dm_channels' for listing DMs or 'discord_send_message' for messaging without channel creation. This lack of context makes it harder for an agent to decide appropriately.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Delete a message' implies a destructive mutation, but it doesn't specify critical details like whether deletion is permanent, requires specific user permissions, has rate limits, or what happens on success/failure. This is a significant gap for a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action, making it easy to parse quickly, which is ideal for conciseness in a tool definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a destructive operation with no annotations or output schema, the description is incomplete. It lacks essential context like behavioral traits (e.g., irreversibility, auth needs), error handling, or return values, making it inadequate for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for channelId and messageId parameters. The description adds no additional semantic information beyond what the schema provides, such as format examples or constraints, so it meets the baseline score when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a message' clearly states the verb (delete) and resource (message), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like discord_edit_message or discord_remove_reaction, which also modify message content or reactions, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites (e.g., needing appropriate permissions), exclusions (e.g., not for bulk deletion), or comparisons to siblings like discord_cleanup_download or discord_remove_reaction, leaving the agent with no usage context.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool downloads and returns an MCP file reference, but doesn't cover critical aspects like authentication needs, rate limits, file size constraints, error handling, or whether it performs network operations that might be slow or fail. This leaves significant gaps for a download 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Download a Discord attachment') and specifies the return type. There is no wasted verbiage, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a download operation with network implications) and the absence of annotations and output schema, the description is incomplete. It doesn't explain what an 'MCP file reference' entails, potential errors, or behavioral traits like caching or file handling. For a tool with no structured safety or output info, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting the 'url' parameter as a Discord CDN URL. The description adds no additional parameter semantics beyond what the schema provides, such as URL format examples or validation rules. With high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download') and resource ('Discord attachment'), specifying it returns an 'MCP file reference'. However, it doesn't explicitly differentiate from sibling tools like 'discord_list_attachments' or 'discord_get_message' which might also handle attachments indirectly, making it clear but not fully sibling-distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. For example, it doesn't mention if this is for downloading attachments from messages retrieved via 'discord_get_message' or 'discord_list_attachments', or if there are prerequisites like having a valid Discord CDN URL. The description lacks context for usage decisions.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Edit' implies a mutation operation, but the description doesn't cover permissions needed (e.g., must be the message author), rate limits, whether edits are reversible, or what happens on success/failure. It lacks critical context for a mutation tool in a chat platform.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place in conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, rate limits, or response format. While the schema covers parameters well, the overall context for safe and effective use is lacking given the tool's complexity and potential side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters clearly documented in the input schema (channelId, messageId, content). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Edit') and resource ('a previously sent message'), making the purpose immediately understandable. It distinguishes from siblings like discord_send_message (create) and discord_delete_message (remove), though it doesn't explicitly mention these distinctions in the description text itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites (e.g., needing the original message ID), compare to discord_send_message for new messages, or specify constraints like time limits for editing in Discord. Usage is implied but not explicitly stated.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets information' but doesn't specify what kind of information (e.g., name, type, permissions), whether it's a read-only operation, if it requires authentication, or any rate limits. This leaves significant gaps for an agent to understand the tool's behavior beyond basic retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and efficiently communicates the core action, 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and no output schema, the description is incomplete. It doesn't explain what information is returned (e.g., channel details like name or type), which is crucial for a retrieval tool. While the schema covers the input well, the overall context for understanding the tool's full behavior is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'channelId' clearly documented as 'The Discord channel ID'. The description adds no additional meaning beyond this, such as format examples or constraints. According to the rules, with high schema coverage, the baseline is 3, which is appropriate here as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'information about a Discord channel', making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'discord_get_message' or 'discord_get_dm_channels', which also retrieve information about Discord entities, so it misses the opportunity to clarify its specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. For example, it doesn't specify if this is for retrieving channel metadata versus message content (which might be handled by 'discord_get_message'), or when to use it over 'discord_get_dm_channels' for direct messages. There's no mention of prerequisites or context for usage.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get message history') but doesn't cover critical aspects like whether this is a read-only operation (implied but not explicit), rate limits, authentication needs, pagination behavior, or error handling. The mention of 'optional filtering' hints at functionality but lacks detail on how filtering works or what the output looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get message history from a Discord channel') and adds a useful qualifier ('with optional filtering'). There's no wasted verbiage or redundancy, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain the return format (e.g., list of messages, metadata), error conditions, or how filtering parameters (before, after, around) function in practice. For a data retrieval tool in a collaborative environment like Discord, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all 5 parameters (channelId, limit, before, after, around) with their types, constraints, and purposes. The description adds minimal value beyond this, only vaguely referencing 'optional filtering' without explaining which parameters enable filtering or how they interact. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('message history from a Discord channel'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'discord_get_message' (singular) or 'discord_search_messages', which might have overlapping functionality. The mention of 'optional filtering' adds specificity but doesn't fully distinguish it from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'discord_get_message' (for a single message) or 'discord_search_messages' (which might offer more advanced filtering). There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage based on tool names alone.
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?
With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions scanning 'recent messages' but doesn't specify ordering, pagination, rate limits, permissions needed, or what 'list' returns (e.g., format, fields). For a tool with 5 parameters and no annotations, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by specifying the action, resource, and scope ('from recent messages'), making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., how 'recent' is defined, return format), usage context versus siblings, and doesn't compensate for the absence of structured output information, making it insufficient for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no parameter-specific semantics beyond implying attachment filtering through 'imageOnly' and size constraints, which are already covered in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all attachments') and resource ('in a Discord channel from recent messages'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'discord_search_messages' or 'discord_get_message_history' which might also involve message scanning, missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'discord_search_messages' or 'discord_get_message_history' that might serve similar purposes. It lacks explicit when/when-not instructions or named alternatives, offering only basic context.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Remove' or 'cancel') but doesn't disclose critical traits such as whether this is a destructive operation, if it requires specific permissions, what happens on success/failure, or any rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the purpose without any fluff or redundancy. It is front-loaded and every word earns its place, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a mutation operation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, return values, error handling, or usage context, which are essential for an agent to invoke it correctly and safely. The high schema coverage doesn't compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'userId' parameter clearly documented as 'User ID to remove as friend'. The description doesn't add any meaning beyond this, such as format examples or constraints, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove' or 'cancel') and the resource ('a friend' or 'a friend request'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'discord_get_friends' (which lists friends) or 'discord_add_friend' (which adds friends), though the verb 'remove' inherently contrasts with 'add'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 clarifying if it applies to existing friends or pending requests, or mentioning prerequisites like having the user as a friend first. It lacks explicit when/when-not instructions or named alternatives, leaving usage context implied at best.
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?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral aspects like required permissions (e.g., manage messages or self-reaction removal), whether it's idempotent, rate limits, or what happens on success/failure. 'Remove' implies mutation, but details are lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and target, making it easy to parse quickly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a mutation tool. It doesn't cover permissions, side effects, error conditions, or return values. While concise, it lacks necessary context for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond implying the tool uses channelId, messageId, and emoji (via 'from a message' and 'reaction'), but this is redundant with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('remove a reaction') and target ('from a message'), which is specific and unambiguous. It doesn't explicitly differentiate from sibling tools like discord_add_reaction or discord_delete_message, but the verb 'remove' versus 'add' or 'delete' provides inherent distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It doesn't mention prerequisites (e.g., needing message access), exclusions, or comparisons to related tools like discord_delete_message (which removes entire messages) or discord_add_reaction (its inverse).
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?
With no annotations provided, the description carries full burden but reveals little behavioral information. It mentions 'filters' but doesn't explain search behavior (e.g., partial/full text matching, case sensitivity), rate limits, authentication requirements, or what happens when no results are found. For a search tool with 9 parameters, this leaves significant gaps in understanding how it actually behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's front-loaded with the main action and includes key aspects (search, text query, filters). Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 9 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the search returns (message objects? summaries?), how results are ordered, pagination behavior, or error conditions. The combination of complex functionality with minimal description leaves the agent poorly equipped to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds minimal value beyond stating 'text query and filters' - it doesn't explain parameter interactions, default behaviors, or provide examples. With high schema coverage, the baseline of 3 is appropriate as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for messages in a Discord channel with text query and filters. It specifies the verb 'search' and resource 'messages in a Discord channel', distinguishing it from siblings like discord_get_message (single message) or discord_get_message_history (chronological list). However, it doesn't explicitly differentiate from potential similar search tools if they existed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention when this search tool is preferred over discord_get_message_history (which might retrieve messages without search) or other message-related tools. There's no context about prerequisites, limitations, or typical use cases.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the optional file attachment capability (up to 10 files), which is useful context. However, it fails to disclose critical behavioral traits: whether this is a read-only or destructive operation (it's clearly a write operation), potential rate limits, authentication requirements, error conditions, or what happens on success (e.g., returns a message ID). The description is minimal and leaves significant 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes the key optional feature. There's no wasted language or redundancy, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a message-sending tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, rate limits, or response format, nor does it provide usage guidelines. For a tool that performs a write operation in a chat platform, more context is needed to ensure safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 5 parameters. The description adds marginal value by mentioning the optional file attachment feature, which aligns with the 'files' parameter. However, it doesn't provide additional semantic context beyond what's in the schema, such as explaining interactions between parameters or usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a message') and target ('to a Discord channel'), with an optional feature ('with up to 10 files'). It distinguishes from siblings like discord_edit_message or discord_delete_message by focusing on message creation. However, it doesn't explicitly differentiate from discord_create_dm, which might also send messages but to DMs rather than channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. For example, it doesn't mention when to choose discord_send_message over discord_edit_message for updates, or discord_create_dm for direct messages. There's also no information about prerequisites, such as needing channel access or bot permissions.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Update' implies a mutation operation, the description doesn't disclose important behavioral aspects like whether this requires authentication, what permissions are needed, whether changes are reversible, or how the update affects other Discord clients.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a tool with good schema documentation and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after the update, what errors might occur, or provide any behavioral context beyond the basic operation. The schema handles parameter documentation well, but the description fails to compensate for the lack of annotations and output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, providing complete documentation for all 3 parameters and their nested structure. The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('your Discord presence/status'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'discord_clear_presence' - both involve presence manipulation but with different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts, or comparison with the sibling 'discord_clear_presence' tool that also handles presence.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a mutation action ('Send a friend request'), but fails to mention permissions needed, rate limits, whether the request is reversible, or what happens on success/failure. This leaves significant gaps for a tool that likely involves user interactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words or fluff. It's appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a social action like sending a friend request, the description is incomplete. With no annotations, no output schema, and no behavioral details, it lacks information on permissions, response format, error handling, or how it differs from sibling tools. This makes it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning there are no parameters to document. The description doesn't add parameter details beyond this, but since no parameters exist, a baseline of 4 is appropriate as it doesn't need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a friend request') and target ('to a user'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'discord_remove_friend' or 'discord_get_friends' beyond the basic action, missing explicit scope or boundary details that would warrant a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'discord_remove_friend' or 'discord_get_friends', nor are there any prerequisites, exclusions, or contextual hints mentioned. The description merely states what it does without advising on usage 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?
With no annotations provided, the description carries full burden but offers limited behavioral insight. It implies a destructive operation ('clean up') but doesn't specify what cleanup entails (e.g., deletion, archiving, permissions changes), whether it's reversible, or any side effects. More context about the operation's nature would be needed for adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent simplicity (one parameter, no output schema, no annotations), the description is minimally adequate but leaves gaps. It doesn't clarify the cleanup behavior or output expectations, which could be important for a destructive operation. However, the high schema coverage and conciseness partially offset these limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% with one parameter ('path') clearly documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides (e.g., format examples, constraints), so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('clean up') and the target ('previously downloaded Discord attachment file'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'discord_delete_message' or 'discord_remove_reaction' that might also involve cleanup operations, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by specifying 'previously downloaded' context, but doesn't explain when to use this tool versus alternatives (e.g., system file deletion tools) or when not to use it (e.g., for non-downloaded files). No explicit alternatives or exclusions are mentioned.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Clear') but doesn't explain what 'presence/activity' entails, whether this affects status or game activity, if it's reversible, or any side effects. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero waste. It's front-loaded and efficiently communicates the core action without unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (implied by 'Clear') with no annotations and no output schema, the description is incomplete. It lacks details on behavior, effects, or return values, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, earning a baseline score of 4 for this context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear') and the resource ('your Discord presence/activity'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'discord_update_presence', but the verb 'Clear' versus 'Update' provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'discord_update_presence' (which might set a new presence). There's no mention of prerequisites, context, or exclusions, leaving usage entirely implicit.
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?
No annotations are provided, so the description carries full burden. It mentions 'full attachment details' as a behavioral trait, which is useful. However, it lacks critical information: whether this is a read-only operation (implied but not stated), rate limits, authentication requirements, error handling (e.g., if message doesn't exist), or response format. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get a specific message by ID') and adds a key detail ('with full attachment details'). There is no wasted verbiage or redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 simple parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and a key feature (attachment details), but lacks behavioral context (e.g., safety, errors) and usage guidance. With no output schema, it doesn't explain return values, which is a gap for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters (channelId and messageId). The description adds no parameter-specific information beyond what the schema provides, such as format examples or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a specific message by ID'), specifying it retrieves full attachment details. It distinguishes from siblings like discord_get_message_history (which retrieves multiple messages) and discord_list_attachments (which lists attachments separately). However, it doesn't explicitly contrast with discord_search_messages or discord_get_channel, which could also retrieve messages indirectly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention when to prefer discord_get_message over discord_get_message_history (for single vs. multiple messages), discord_search_messages (for searching vs. direct ID lookup), or discord_list_attachments (for attachments only vs. full message). No prerequisites or exclusions are stated.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't mention whether it requires authentication, how it handles rate limits, what the return format looks like, or if there are any side effects. For a read operation with zero annotation coverage, this leaves significant 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose but lacks details on behavioral aspects like return format or authentication needs, which are relevant even for simple tools. It meets the minimum viable threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to add parameter information, and it correctly implies no inputs are required, aligning with the schema. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('list of DM channels for the current user'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like discord_get_channel or discord_get_friends, but the specificity of 'DM channels' provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 discord_get_channel (which might retrieve different channel types) or discord_create_dm (for creating new DMs). The description implies usage for listing existing DM channels but lacks explicit context or exclusions.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it retrieves a list but doesn't specify format, pagination, rate limits, authentication requirements, or error conditions. This is a read operation, but the lack of details makes it minimally transparent for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function without any fluff or redundancy. It's front-loaded and efficiently communicates the core purpose, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It covers the basic purpose but lacks details on return format, error handling, or integration with sibling tools. For a read operation in a social context, more context could help the agent use it effectively, but it's minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate here. A baseline of 4 is applied as it meets expectations for a parameterless tool without unnecessary elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get list') and resource ('friends for the current user'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'discord_get_dm_channels' or 'discord_get_channel', which also retrieve user-specific data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. For example, it doesn't mention if this is for viewing all friends versus filtered lists, or how it relates to other social interaction tools like 'discord_add_friend' or 'discord_remove_friend'. This leaves the agent to infer usage from context alone.
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
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/BennettSchwartz/discord-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server