Server Quality Checklist

Tool Scores

• discord_get_channelC
  2.6/5.0
  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 tool 'Get information', implying a read-only operation, but does not disclose any behavioral traits such as authentication requirements, rate limits, error handling, or what specific information is returned (e.g., channel name, type, permissions). This is a significant gap for a tool with no 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence: 'Get information about a Discord channel'. It is front-loaded and wastes no words, making it easy to parse. However, it could be slightly more informative without sacrificing conciseness, such as hinting at the type of information retrieved.

  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?

  Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It does not explain what information is returned (e.g., channel details like name or type), any dependencies, or error cases. For a read operation with no structured output, more context is needed to guide the agent effectively.

  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 has 100% description coverage, with the parameter 'channelId' documented as 'The Discord channel ID'. The description does not add any meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool's purpose as 'Get information about a Discord channel', which is clear but vague. It specifies the verb ('Get') and resource ('Discord channel'), but does not distinguish it from siblings like 'discord_get_message' or 'discord_get_dm_channels' in terms of what specific information is retrieved. It avoids tautology by not merely restating the name.

  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 any context, prerequisites, or exclusions, such as when to use it over 'discord_get_dm_channels' for direct messages or 'discord_get_message' for message details. This lack of usage context leaves the agent without direction.

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

• discord_add_reactionC
  2.9/5.0
  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. While 'Add a reaction' implies a write/mutation operation, it doesn't specify required permissions, rate limits, whether reactions are reversible, or what happens on success/failure. This leaves significant behavioral gaps 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for a straightforward 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.

  Completeness2/5

  Given 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 execution (success indicators, error conditions), nor does it provide context about permissions or limitations. The 100% schema coverage helps with parameters but doesn't compensate for missing behavioral context.

  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 100%, with all three parameters clearly documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema, so it meets the baseline for adequate coverage without adding value.

  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 ('Add a reaction') and the target ('to a message'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'discord_remove_reaction', which performs the opposite action on the same resource type.

  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 doesn't mention prerequisites (like needing appropriate permissions), nor does it differentiate from related tools like 'discord_remove_reaction' or 'discord_edit_message' (which might also modify message appearance).

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

• discord_cleanup_downloadC
  2.9/5.0
  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. It states the tool cleans up files but doesn't explain what 'clean up' entails (e.g., deletion, archiving, moving), whether it's reversible, requires permissions, or has side effects. This leaves significant gaps for a tool that likely modifies system state.

  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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part contributing essential 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?

  For a tool with no annotations, no output schema, and a potentially destructive operation ('clean up'), the description is insufficient. It lacks details on behavior, outcomes, error conditions, or integration with sibling tools like 'discord_download_attachment', leaving the agent with incomplete context for safe and effective use.

  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 100%, with the single parameter 'path' documented in the schema. The description adds no additional parameter semantics beyond implying the path should point to a downloaded attachment, which is minimal value. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

  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 ('clean up') and resource ('previously downloaded Discord attachment file'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'discord_delete_message' or 'discord_clear_presence' that might also involve cleanup operations, 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides minimal guidance by specifying 'previously downloaded' files, implying usage after download operations. However, it offers no explicit when-to-use vs. alternatives, no prerequisites, and no context about when this tool should be preferred over other cleanup methods or tools.

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

• discord_delete_messageC
  2.9/5.0
  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. 'Delete a message' implies a destructive, irreversible mutation, but lacks details on permissions required (e.g., bot vs. user rights), rate limits, error conditions (e.g., message not found), or side effects (e.g., audit logs). This is inadequate for a destructive operation 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence with zero wasted words. It's front-loaded with the core action, making it highly efficient. Every word earns its place by conveying the essential purpose without 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?

  For a destructive tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, reversibility, or response format, leaving significant gaps for the agent to operate safely and effectively. More context is needed given the tool's complexity and lack of structured data.

  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 100%, with clear descriptions for channelId and messageId. The description adds no parameter-specific information beyond what the schema provides (e.g., format examples, sourcing hints). Baseline 3 is appropriate since the schema does the heavy lifting, but no extra value is added.

  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 'Delete a message' clearly states the verb (delete) and resource (a message), making the purpose immediately understandable. It distinguishes from siblings like discord_edit_message (modify) and discord_get_message (retrieve), but doesn't specify what type of message (e.g., user's own vs. others') or context beyond what's implied by the tool name.

  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 doesn't mention prerequisites (e.g., needing permissions), when not to use it (e.g., for bulk deletion), or refer to related tools like discord_edit_message for modification instead of deletion. The agent must infer usage from the tool name alone.

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

• discord_edit_messageC
  2.9/5.0
  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. While 'Edit' implies a mutation operation, the description doesn't address critical behavioral aspects: permission requirements, rate limits, whether edits are reversible, how Discord handles edit history, or what happens if the message doesn't exist. For a mutation tool with zero annotation coverage, this leaves the agent with insufficient operational context.

  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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a straightforward editing operation and front-loads the essential information. Every word earns its place, 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/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after editing (success/failure responses), error conditions, or behavioral constraints. While the schema covers parameters well, the operational context for a Discord message edit requires more guidance about permissions, limitations, and outcomes than the current description provides.

  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 100%, with all three parameters clearly documented in the schema (channelId, messageId, content with maxLength). The description adds no additional parameter information beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

  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 ('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. The verb+resource combination is specific but could be more precise about what aspects can be edited.

  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 doesn't mention prerequisites (e.g., needing to have sent the message or have appropriate permissions), when editing is appropriate versus deleting/resending, or how it differs from similar operations. With multiple message-related siblings (send_message, delete_message, get_message), this lack of contextual guidance is a significant gap.

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

• discord_get_message_historyC
  2.9/5.0
  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 describe important behavioral traits: whether this is a read-only operation, rate limits, authentication requirements, pagination behavior, error conditions, or what the return format looks like. For a tool with 5 parameters and no output schema, this leaves significant gaps in understanding how the tool 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that states the core purpose upfront. There's no wasted language or unnecessary elaboration. It's appropriately sized for a tool with this level of complexity and gets straight to the point without sacrificing clarity.

  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 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the return format, error handling, rate limits, or authentication requirements. While the schema covers parameter documentation well, the description fails to provide the behavioral context needed for an agent to use this tool effectively in real scenarios.

  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 description mentions 'optional filtering' which hints at the purpose of parameters like before, after, and around, but doesn't explain their semantics or relationships. With 100% schema description coverage, the schema already documents all parameters well, so the description adds minimal value beyond what's in the structured data. The baseline of 3 is appropriate when 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/5

  Does 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 immediately understandable. It distinguishes this tool from siblings like discord_get_message (singular) and discord_search_messages by specifying it retrieves historical messages rather than a single message or search results. However, it doesn't explicitly contrast with all siblings, so it's not a perfect 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 provides no guidance on when to use this tool versus alternatives. It mentions 'optional filtering' but doesn't specify when to use filtering parameters or how this differs from discord_search_messages. There's no mention of prerequisites, limitations, or typical use cases, leaving the agent with insufficient context for optimal tool selection.

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

• discord_list_attachmentsC
  2.9/5.0
  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. While it mentions scanning 'recent messages' and listing attachments, it doesn't specify important behavioral aspects like whether this is a read-only operation, how messages are selected (chronologically?), what format the results come in, whether there are rate limits, or what happens with large channels. The description is insufficient for a tool with 5 parameters and no 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for the tool's complexity and gets straight to the point with zero wasted text.

  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 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (list format, what fields are included), doesn't mention important behavioral constraints, and provides minimal guidance on usage. The description should do more heavy lifting given the lack of structured metadata.

  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 description mentions 'recent messages' which relates to the 'limit' parameter, and 'attachments' which relates to the filtering parameters. However, with 100% schema description coverage, all parameters are already documented in the schema. The description adds minimal value beyond what the schema provides, meeting 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/5

  Does 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 tool's purpose immediately understandable. However, it doesn't differentiate itself from sibling tools like 'discord_search_messages' or 'discord_get_message_history' that might also retrieve message content including attachments, missing an opportunity for clear 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/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 like 'discord_search_messages' or 'discord_get_message_history' that could also retrieve attachments. It doesn't mention prerequisites, constraints, or typical use cases, leaving the agent to infer usage context from the tool name alone.

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

• discord_remove_friendC
  2.9/5.0
  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 mentions the action ('Remove' or 'cancel') but does not specify permissions required, whether the action is reversible, rate limits, or response behavior. 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and front-loaded, using only six words to convey the core action. Every word earns its place without redundancy, 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/5

  Given 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 aspects like permissions, reversibility, and response format, which are crucial for safe and effective use. The high schema coverage helps with parameters but does not compensate for the overall gaps.

  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 description coverage is 100%, with the parameter 'userId' clearly documented in the schema. The description does not add any additional meaning or context beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, 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/5

  Does 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 evident. It distinguishes between removing an existing friend and canceling a pending request, which adds specificity. However, it does not explicitly differentiate from sibling tools like 'discord_get_friends' beyond the obvious action difference, so it falls short of 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/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 when to remove a friend versus canceling a request, or prerequisites like needing the user ID. It lacks explicit context or exclusions, leaving usage unclear beyond the basic action stated.

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

• discord_remove_reactionC
  2.9/5.0
  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. While 'Remove' implies a destructive operation, it doesn't specify required permissions, whether the action is reversible, rate limits, or what happens if the reaction doesn't exist. For a mutation 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/5

  Is 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/5

  Given 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, side effects, error conditions, or return values. The 100% schema coverage helps with parameters, but overall context for safe/effective use is lacking.

  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 100%, so all parameters are documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema (like explaining emoji format nuances or userId default behavior). Baseline 3 is appropriate when schema does the heavy lifting.

  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 ('Remove a reaction') and target ('from a message'), providing a specific verb+resource combination. It distinguishes from obvious siblings like 'discord_add_reaction' by specifying removal rather than addition, though it doesn't explicitly mention all sibling tools.

  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 doesn't mention prerequisites (like needing appropriate permissions), when not to use it, or how it relates to sibling tools like 'discord_delete_message' or 'discord_edit_message' for message modifications.

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

• discord_search_messagesC
  2.9/5.0
  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. The description mentions 'search' and 'filters' but doesn't clarify key behaviors: whether this is a read-only operation, what permissions are required, how results are returned (e.g., pagination, format), rate limits, or error conditions. For a search tool with 9 parameters and no annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does ('Search for messages in a Discord channel') and adds key context ('with text query and filters') in a compact form. Every part of the sentence contributes meaning.

  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?

  Given the tool's complexity (9 parameters, search functionality) and lack of annotations and output schema, the description is insufficient. It doesn't explain the return format, error handling, or behavioral constraints like rate limits or permissions. For a search tool in a messaging context, more detail on results and usage boundaries is needed to be complete.

  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 100%, meaning all parameters are documented in the input schema. The description adds minimal value beyond the schema by mentioning 'text query and filters', which aligns with parameters like 'query', 'authorId', and date filters. However, it doesn't provide additional context, examples, or clarification on parameter interactions, so it meets the baseline for high schema coverage.

  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's purpose: 'Search for messages in a Discord channel with text query and filters'. It specifies the verb ('search'), resource ('messages in a Discord channel'), and scope ('with text query and filters'). However, it doesn't explicitly differentiate from sibling tools like 'discord_get_message_history' which might also retrieve messages, though the filtering aspect 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/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 doesn't mention sibling tools like 'discord_get_message_history' or 'discord_get_message', nor does it specify prerequisites, exclusions, or contextual usage scenarios. The agent must infer usage based on the name and description alone.

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

• discord_add_friendB
  3.1/5.0
  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 but doesn't cover permissions needed, rate limits, response format, or potential errors. This leaves significant gaps for a mutation tool, though it correctly implies a write 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, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and wastes no space, 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/5

  Given 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 details on behavioral traits, response handling, and error conditions, which are crucial for proper tool invocation. The simplicity of 0 parameters 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.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 0 parameters with 100% coverage, so the description doesn't need to compensate for undocumented parameters. The baseline is 4 since no parameter information is required, and the description appropriately focuses on the tool's purpose without redundant details.

  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 ('Send a friend request') and target resource ('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', which prevents 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/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 like 'discord_remove_friend' or 'discord_get_friends', nor does it mention prerequisites or context for sending friend requests. It merely states what the tool does without usage context.

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

• discord_clear_presenceB
  3.1/5.0
  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 'clear' entails—whether it resets to default, removes all activity, or has side effects. It also omits details like permissions needed, rate limits, or error conditions, which are critical 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence that efficiently conveys the core action without unnecessary words. It's front-loaded with the key verb and resource, making it easy to scan and understand immediately. There's no wasted language or redundant 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?

  Given the complexity of a mutation tool (clearing presence) with no annotations and no output schema, the description is incomplete. It lacks details on behavioral outcomes (e.g., what 'clear' means in practice), error handling, or return values. For a tool that modifies user state, more context is needed to ensure safe and correct usage.

  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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't add parameter-specific information, which is unnecessary here. A baseline of 4 is appropriate as the schema handles all parameter documentation, and the description 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/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Clear') and resource ('your Discord presence/activity'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'discord_update_presence' by focusing on removal rather than modification. However, it doesn't specify what 'presence/activity' entails (e.g., status, game activity, custom status), leaving some 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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing to be logged in), when it's appropriate (e.g., after setting a presence), or what happens if there's no presence to clear. Without this context, users must infer usage from the tool name alone.

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

• discord_download_attachmentB
  3.1/5.0
  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 downloading and returning an MCP file reference, but lacks details on behavioral traits: it doesn't specify if this requires authentication, rate limits, file size constraints, error handling, or what happens if the URL is invalid. For a download operation 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that front-loads the core action and outcome. Every word earns its place: 'Download a Discord attachment' specifies the action, 'and return it as MCP file reference' clarifies the output. There is no wasted verbiage or redundancy.

  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 one parameter with full schema coverage and no output schema, the description is minimally adequate. It explains what the tool does but lacks context on usage, behavioral details, or output specifics (beyond 'MCP file reference'). For a download tool with no annotations, it should do more to guide the agent, but it meets a basic threshold.

  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 100%, with the single parameter 'url' fully documented in the schema as a Discord CDN URL. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples or format clarifications). Baseline 3 is appropriate when 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/5

  Does 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. It distinguishes from siblings like discord_list_attachments (which lists rather than downloads) and discord_send_message (which sends rather than downloads). However, it doesn't explicitly contrast with all siblings, keeping it at 4 rather than 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid Discord CDN URL), exclusions, or related tools like discord_list_attachments for finding attachments to download. Without such context, the agent must infer usage from the tool name alone.

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

• discord_get_dm_channelsB
  3.1/5.0
  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. It states the action but lacks details on permissions required, rate limits, pagination, return format, or error conditions. 'Get list' suggests a read-only operation, but this isn't explicitly confirmed, leaving gaps in transparency for a tool that likely interacts with user data.

  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 efficiently conveys the core functionality without unnecessary words. It's front-loaded with the essential action and resource, making it easy to parse. Every part of the sentence earns its place by specifying DM channels and the current user scope.

  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?

  Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns structured data. It doesn't explain what the list contains (e.g., channel IDs, names, metadata), how results are formatted, or any limitations. For a read operation in a complex API like Discord, more context is needed to use it effectively.

  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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately omits parameter details, focusing on the tool's purpose. This meets the baseline for tools with no parameters, as there's nothing to compensate for.

  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 verb ('Get') and resource ('list of DM channels for the current user'), making the purpose immediately understandable. It distinguishes from siblings like discord_get_channel (general channel) and discord_get_friends (friends list), though it doesn't explicitly contrast them. The description avoids tautology by specifying the resource type and 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/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 doesn't mention prerequisites (e.g., authentication state), compare to discord_create_dm (for creating new DMs) or discord_get_message_history (for message content), or specify scenarios where this tool is appropriate. Usage is implied but not articulated.

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

• discord_get_friendsB
  3.1/5.0
  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 only states the basic action without covering critical aspects like whether this is a read-only operation, potential authentication requirements, rate limits, error conditions, or the structure of the returned data. For a 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence that efficiently conveys the core purpose without any wasted words. It is front-loaded and appropriately sized for a simple tool, 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/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the returned list contains (e.g., friend IDs, names, statuses), how errors are handled, or any dependencies (e.g., user must be logged in). For a tool that likely interacts with user data, this leaves too many unknowns for reliable agent use.

  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 tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it appropriately avoids redundant information. A baseline of 4 is justified since there are no parameters to document.

  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 verb ('Get') and resource ('list of friends for the current user'), making the purpose unambiguous. It distinguishes from siblings like discord_add_friend or discord_remove_friend by focusing on retrieval rather than modification. However, it doesn't specify the format or scope of the returned list, which prevents 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/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 doesn't mention prerequisites (e.g., authentication status), compare to similar tools like discord_get_dm_channels, or indicate limitations (e.g., rate limits). This leaves the agent with insufficient context for optimal tool selection.

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

• discord_update_presenceB
  3.1/5.0
  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. 'Update' implies a mutation operation, but the description doesn't disclose whether this requires specific permissions, whether changes are immediate or delayed, what happens if invalid parameters are provided, or any rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with clear purpose and good schema documentation, 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 mutation tool with no annotations and no output schema, the description provides basic purpose but lacks important context about behavioral characteristics, error conditions, or return values. The 100% schema coverage helps with parameter understanding, but the overall description feels minimal for a tool that modifies user state in a social platform.

  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 description coverage is 100%, meaning all parameters are well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description.

  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 ('Update') and target ('your Discord presence/status'), making the purpose immediately understandable. It distinguishes this tool from most siblings which handle messaging, channels, friends, or attachments rather than user status. However, it doesn't explicitly differentiate from 'discord_clear_presence' which is a closely related sibling.

  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 doesn't mention the sibling 'discord_clear_presence' (which likely clears presence rather than updates it), nor does it indicate any prerequisites, constraints, or appropriate contexts for updating presence versus other status-related actions.

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

• discord_create_dmB
  3.2/5.0
  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. It mentions the tool can 'create or get existing' a DM, which hints at idempotent behavior, but lacks details on permissions required, rate limits, error conditions (e.g., invalid user ID), or what happens if the user is not reachable. For a tool that interacts with user channels, this is a significant gap in behavioral context.

  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, efficient sentence that directly states the tool's function without any fluff. It is appropriately sized and front-loaded, making it easy 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?

  Given the tool's moderate complexity (creating or retrieving a DM channel), lack of annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but misses behavioral details like return values (e.g., channel ID or error messages), which are crucial for an agent to use it effectively. This leaves gaps in completeness.

  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 description adds no specific parameter information beyond what the schema provides (100% coverage with a clear 'userId' description). However, with only one parameter and high schema coverage, the baseline is strong. The description's focus on 'with a user' implicitly reinforces the userId parameter's role, but doesn't add new semantics. A score of 4 reflects that minimal compensation is needed given the simple schema.

  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 verb ('create or get') and resource ('DM channel with a user'), making the purpose specific and understandable. It doesn't explicitly distinguish from sibling tools like 'discord_get_dm_channels' (which likely lists all DMs) or 'discord_get_channel' (which might retrieve any channel), but the focus on a single user DM is reasonably clear.

  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 doesn't mention prerequisites (e.g., needing to be friends with the user), when to prefer it over 'discord_get_dm_channels' for existing DMs, or any exclusions. 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.

• discord_get_messageB
  3.3/5.0
  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 tool retrieves a message with 'full attachment details', which adds some context about return content. However, it lacks critical behavioral information such as whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or what 'full attachment details' entails. This leaves significant gaps for an agent to understand the tool's 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 a single, efficient sentence that front-loads the core action ('Get a specific message by ID') and adds a key detail ('with full attachment details'). There is no wasted verbiage, and it directly communicates the tool's function without 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/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's low complexity (2 parameters, no nested objects) and high schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it fails to fully compensate for missing behavioral and output details. The mention of 'full attachment details' provides some output context, but without an output schema, this remains vague. The description is complete enough for basic understanding but lacks depth for reliable agent 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 input schema has 100% description coverage, with clear documentation for both parameters (channelId and messageId). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

  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 verb 'Get' and the resource 'a specific message by ID', making the purpose evident. It distinguishes from siblings like discord_get_message_history (which retrieves multiple messages) by specifying retrieval of a single message. However, it doesn't explicitly contrast with discord_search_messages, which might also retrieve specific messages, leaving slight ambiguity.

  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 usage when needing a single message with full attachment details, but provides no explicit guidance on when to use this versus alternatives like discord_get_message_history or discord_search_messages. It mentions 'full attachment details', which hints at a use case but doesn't state prerequisites or exclusions, leaving usage context partially inferred.

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

• discord_send_messageB
  3.3/5.0
  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. While it mentions the optional file attachment capability, it fails to disclose critical behavioral traits such as rate limits, authentication requirements, error conditions (e.g., invalid channel ID), whether messages are persistent, or what happens if content exceeds 2000 characters (though schema covers this). For a write operation 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that is front-loaded with the core purpose ('Send a message to a Discord channel') and adds a useful detail ('optionally with up to 10 files'). There is no wasted language 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/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (a write operation with 5 parameters, no annotations, and no output schema), the description is minimally adequate but incomplete. It covers the basic purpose and file attachment capability but lacks behavioral context (e.g., permissions, errors) and usage guidelines. The high schema coverage helps, but for a mutation tool without annotations, more disclosure would be beneficial.

  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 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value beyond the schema by mentioning the optional file attachment with a quantity limit ('up to 10 files'), which is already implied in the schema's maxItems. No additional semantic context (e.g., channelId format, file types supported) is provided, so the baseline 3 is appropriate.

  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 specific action ('Send a message to a Discord channel') and resource ('Discord channel'), with additional functionality ('optionally with up to 10 files'). It distinguishes itself from sibling tools like discord_edit_message (edits existing messages) and discord_delete_message (removes messages) by focusing on message creation.

  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 doesn't mention prerequisites (e.g., needing channel access), when to use discord_edit_message instead for updates, or how it differs from discord_create_dm for direct messages. The optional file attachment is noted but without context about limitations or alternatives.

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