Server Quality Checklist

Tool Scores

• execute_webhookC
  2.9/5.0
  Behavior1/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 action (sending a message) without any information about side effects, authentication requirements, rate limits, idempotency, or error conditions. As a mutation tool, this is a significant gap with essentially no 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.

  Conciseness4/5

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

  The description is a single concise sentence, efficiently front-loaded with the core action. It contains no redundant fluff, but it is slightly under-specified for a mutation tool, earning a 4 rather than 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

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

  With no annotations and no output schema, the description is the primary source of context. It lacks information about return values, error behavior, effect on the Discord channel, or how the webhook ID/token are used. For a 3-parameter mutation tool, this is significantly incomplete, making it difficult for an agent to anticipate the outcome.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

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

  Schema coverage is 100%, with all three parameters (content, webhookId, webhookToken) having descriptions. The description itself adds no parameter-level semantics beyond the action, but the schema is sufficient for understanding parameters. Baseline for high coverage is 3.

  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 'Discord Webhookを実行してメッセージを送信します' (Execute Discord webhook and send a message), using a specific verb (execute) and resource (webhook) with a direct action. This distinguishes it from sibling tools like get_webhook, create_webhook, and delete_webhook, as well as from generic send_message. The purpose is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage 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 that this is for webhook-based messaging as opposed to regular send_message, nor does it provide any exclusions or prerequisites such as needing a valid webhook ID and token.

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

• send_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. It only states the action without revealing side effects, permissions, rate limits, or that it is a write operation beyond the inherent verb. For a tool that creates messages, 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.

  Conciseness4/5

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

  The description is a single, clear sentence with no unnecessary words. It is concise and front-loaded, but its brevity leaves out useful context that would make it more helpful.

  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?

  While the schema richly documents parameters, the description lacks critical context such as when to use this tool, potential side effects, or return behavior. As a mutation tool with no annotations and no output schema, the description is insufficient for an agent to fully understand the tool's place in the workflow.

  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 already provides descriptions for all parameters (100% coverage), including limits and defaults. The description adds no additional parameter semantics, but given the high schema coverage, a 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 tool's function: 'sends a message to a Discord channel', using a specific verb and resource. It is distinct from sibling tools like send_file, though it does not explicitly differentiate itself from them or mention that it supports embeds and TTS.

  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 send_file or execute_webhook. There is no mention of use cases, prerequisites, or exclusions, leaving the agent without context for tool selection.

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

• update_webhookC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description must fully disclose behavioral traits, but it only states 'updates'. It does not mention whether the update is partial or full, any required permissions, side effects, or response behavior. This is a significant transparency 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.

  Conciseness4/5

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

  The description is a single, short sentence with no wasted words. It is front-loaded with the action and resource, though it is arguably too terse to fully convey the tool's purpose or behavior.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

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

  The description provides minimal context beyond the tool's name. It lacks usage guidance, behavioral details, and clarification of update semantics (e.g., optional fields, partial update behavior). For a simple tool this is inadequate, especially without annotations or output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

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

  The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no parameter-level detail beyond the schema, but the schema already explains name, avatar, and webhookId 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 identifies the action ('更新します' = update) and the target resource ('既存のDiscord Webhook' = existing Discord webhook), distinguishing it from siblings like create_webhook, delete_webhook, and execute_webhook. However, it does not specify what fields are updated, making it slightly generic.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool vs alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent without direction on choosing this over similar webhook tools.

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

• get_guild_rolesB
  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 only states that the tool retrieves a role list, but does not disclose read-only nature, permission requirements, return format, or any side effects. For a simple read operation this is minimal but still lacks detail that could affect usage, such as whether the result is ordered or includes all roles by default.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single, front-loaded sentence that instantly conveys the tool's purpose. No unnecessary words or repetition. It is as concise as possible while remaining informative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

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

  The tool has a simple read operation with four parameters, no output schema, and no annotations. The description gives the basic action but does not mention the optional filtering capabilities or the structure of the returned role list. While the schema covers the parameters, the lack of an output schema means the description could have offered a bit more context about the response format or typical usage, making it minimally adequate.

  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 baseline is 3. The description adds no extra semantic meaning to the parameters beyond what the schema already provides. It does not reference the optional filters (adminOnly, excludeManaged, includeDetails), which are already well-documented in the 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 ('取得します' = 'get') and the resource ('ロール一覧' = 'role list') for a specific Discord server. It is unambiguous about the tool's function. However, it does not explicitly distinguish itself from sibling tools like get_member_roles, though the scope ('server roles' vs 'member roles') is implicit in the wording.

  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. There is no mention of prerequisites, typical use cases, or exclusions. An agent would have no contextual clues to decide between get_guild_roles and get_member_roles beyond the tool name.

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

• send_fileB
  3.1/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the action (send file) without mentioning file size limits, permission requirements, rate limits, error behavior, or the success/failure response format. For a mutation tool, this is a significant transparency gap.

  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, concise sentence with no wasteful words. It effectively communicates the core function, and while it lacks structured sections like usage notes, its brevity is appropriate for a simple tool. However, it could be slightly more informative without losing conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

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

  Given the tool has a nested object, multiple parameters, and no output schema, the description is incomplete. It does not explain return values, error cases, or special behaviors such as spoiler handling or content length limits. An agent would need to infer these from the schema alone, which is insufficient for full understanding.

  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 provides full descriptions for all 4 parameters, including the nested file object with name, content, and contentType properties, as well as channelId, content, and spoiler. The description adds no additional parameter semantics beyond the generic 'send file', so with 100% 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.

  Purpose5/5

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

  The description clearly states the tool sends a file to a Discord channel, using a specific verb (送信) and resource (channel) with the scope of 'file'. This distinguishes it from sibling send_message by specifying the file component, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like send_message or execute_webhook. There are no prerequisites, exclusions, or contextual clues beyond the basic function, leaving the agent without decision support for tool selection.

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

• get_channel_listB
  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 full responsibility for behavioral disclosure. It only states the basic action without mentioning permissions, rate limits, response format, or whether the list includes categories, voice channels, etc.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single clear sentence with no wasted words. It is immediately understandable and appropriately sized.

  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?

  Although the tool is simple, the lack of an output schema and annotations means the description should provide more context about what the response looks like or any caveats. It does not, leaving the agent with no information about return values or edge cases.

  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 covers 100% of parameters, each with descriptions, so the schema does the heavy lifting. The description adds no parameter-specific information, but since coverage is high, the baseline of 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 tool retrieves the channel list for a specific Discord server, using a specific verb (取得します) and resource (チャンネル一覧). This distinguishes it from sibling tools like get_channel_messages or get_server_details, which serve different purposes.

  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, nor does it mention any exclusions or prerequisites. The context of sibling tools implies it's for listing channels, but that is not explicitly stated.

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

• get_channel_webhooksB
  3.2/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. It does not disclose any behavioral traits beyond the basic 'get' operation, such as return format, pagination, required permissions, or whether it includes inactive webhooks. This is a minimal, surface-level description.

  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 concise sentence with no filler. It is appropriately sized for a simple tool, though it lacks differentiating context that could be expected given the sibling tools. It is not overly verbose, but it also does not go beyond the minimum.

  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 simplicity (1 parameter, no output schema, no annotations), the description is minimally viable. It states the core function but does not elaborate on distinctions from similar webhook tools or expected return values. For a simple read operation, this is barely adequate but leaves 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?

  Schema description coverage is 100% (channelId has a description). The tool description does not add additional meaning to the parameter beyond what the schema already provides. Baseline of 3 is appropriate since the schema fully documents the parameter.

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

  Purpose5/5

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

  The description uses a specific verb (取得 = get) and resource (特定のDiscordチャンネルのWebhook一覧 = list of webhooks for a specific Discord channel), clearly distinguishing it from sibling tools like get_guild_webhooks and get_webhook.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives such as get_guild_webhooks or get_webhook. The description only states what it does, leaving the agent to infer usage context from the tool name and sibling list.

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

• get_messageB
  3.2/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden. It only states 'retrieves detailed information' without disclosing behavioral traits such as read-only nature, permission requirements, error conditions, or return format. It adds no context beyond what the tool's name already implies.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single concise sentence that directly states the action and object. It contains no filler, redundancy, or unnecessary 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?

  The tool has no output schema and no annotations, so the description must clarify what 'detailed information' includes. It only says '詳細情報' without specifying fields or behavior on failure, and it does not relate to sibling tools. This leaves the agent under-informed.

  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 provides complete descriptions for both channelId and messageId (100% coverage). The description does not add extra parameter semantics, so the baseline score of 3 applies.

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

  Purpose5/5

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

  The description uses the verb '取得する' (retrieve) with a clear object '特定のDiscordメッセージの詳細情報' (detailed information about a specific Discord message). It distinguishes itself from sibling tools like get_channel_messages and get_pinned_messages by emphasizing 'specific' message.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. With multiple sibling tools like get_channel_messages and get_pinned_messages, the description does not clarify selection criteria or exclusions, leaving the agent without context for choosing the right tool.

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

• create_webhookB
  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 full responsibility for behavioral disclosure. It only states the action ('creates') without mentioning side effects, permissions required, rate limits, or what is returned. This is insufficient 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, clear sentence with no redundant words. It is appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

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

  The tool is simple and the schema fully documents parameters. However, the description omits any usage context (e.g., typical workflow, permissions, or response format). While not critical for a basic create, it could be more complete given the lack of annotations and output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

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

  The input schema provides complete descriptions for all three parameters (name, avatar, channelId) with 100% coverage. The description adds no extra parameter context, but the schema already does the heavy lifting, so a baseline score of 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 'new Webhook in Discord channel' with a specific verb (create) and resource (webhook). It is distinct from sibling tools like get_webhooks, update_webhook, delete_webhook, and execute_webhook, which cover other webhook 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/5

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

  The description gives no explicit guidance on when to use this tool instead of alternatives like get_channel_webhooks or update_webhook. It lacks any mention of prerequisites or conditions under which creation is appropriate.

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

• get_channel_invitesB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden for behavioral disclosure. It only states the read operation ('取得します') and does not mention permissions, rate limits, response format, or behavior when channel has no invites. Nothing is contradicted, but disclosure is minimal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler. Every word contributes to explaining the tool's purpose, making it highly concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

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

  For a simple one-parameter read tool, the description is minimally adequate. However, it lacks details about the returned invite structure, potential permission requirements, and does not distinguish behavior from get_guild_invites. This creates a gap for an agent deciding between similar tools.

  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% for the single channelId parameter, so the schema already fully documents it. The description adds no extra parameter semantics beyond confirming the channel scope, so a baseline of 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 uses a specific verb ('取得します' = retrieves) and identifies the resource as invite links for a specific Discord channel, clearly differentiating from sibling tools like get_guild_invites which target guild-level invites. The scope is explicit and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool over alternatives such as get_guild_invites. The description only states what it does, without mentioning exclusions or context for choosing it.

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

• get_user_listB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'retrieves user list' without mentioning read-only nature, pagination behavior, or any potential effects. No side effects or permissions are disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single, compact sentence that gets straight to the point with no redundant words. It is 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 (5 parameters including pagination, filtering, and details) and the absence of an output schema, the description is minimal—it states the core purpose but omits behavioral context like pagination or filtering capabilities, although the schema fills in parameter details.

  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 provides complete descriptions for all five parameters (100% coverage), so the description adds no extra parameter meaning. The baseline is 3 because schema covers everything.

  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 explicitly states the verb and resource: '取得します' (retrieve) and '特定のDiscordサーバーのユーザー一覧' (user list of a specific Discord server). This clearly distinguishes it from sibling tools that focus on channels, messages, or roles.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives, and there are no prerequisites or exclusions mentioned. The description solely states the function, leaving the agent to infer context.

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

• get_channel_messagesB
  3.4/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 for behavioral disclosure. It only states the purpose and gives no information about ordering, pagination, permissions, rate limits, or error behavior, which are critical for a tool with multiple filter parameters.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single, concise sentence that directly conveys the core function without unnecessary fluff. It is appropriately sized for the simplicity of the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

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

  With 5 parameters including complex filtering (before/after/around), no output schema, and no annotations, the description is too minimal. It does not explain default behavior (e.g., what is returned when no optional parameters are provided) or the structure of the response, making it incomplete for an agent to confidently use the tool.

  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% coverage with descriptions for all parameters, so the baseline is 3. The description itself does not add any extra semantic meaning beyond what the schema already provides.

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

  Purpose5/5

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

  The description clearly states the tool's function with a specific verb ('取得します' - retrieves) and resource ('Discordチャンネルのメッセージ履歴' - Discord channel message history). This distinguishes it from siblings like get_message (single message) and get_pinned_messages.

  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 usage context is implied by the description (for channel message history), but it does not explicitly state when to use this tool over alternatives or mention any exclusions. It lacks guidance on choosing between this and get_message/get_pinned_messages.

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

• get_member_rolesB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden for behavioral disclosure. It only states that the tool retrieves a member's roles, but does not mention any filtering behavior (e.g., adminOnly attributes), permissions required, response format, or whether it returns full role objects or just IDs. This is a minimal disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single, concise sentence that front-loads the core purpose. It is efficient with no filler or redundant information, 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?

  The tool has 5 parameters and no output schema, yet the description does not explain the return structure, the meaning of the boolean filters in practice, or any edge cases. The description alone would leave an agent uncertain about what data is returned and how to use the optional parameters 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% coverage of parameter descriptions, so the baseline is 3. The description itself adds no parameter-level detail (e.g., how 'includeDetails' changes the response), but the schema already provides sufficient semantics for each parameter.

  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 specifies the verb '取得' (get) and the resource '特定のDiscordサーバーメンバーのロール一覧' (list of roles for a specific Discord server member), distinguishing it from sibling tools like get_guild_roles (server roles) and get_user_list. It accurately states what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

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

  The description implies usage context by specifying '特定の' (specific) member, which differentiates it from broader tools like get_guild_roles. However, it does not explicitly state when to use this tool versus alternatives or any exclusions, leaving the distinction to inference.

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

• get_guild_invitesA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description alone must convey behavioral traits. It states a read operation (取得します) but does not disclose permission requirements (e.g., Manage Server), rate limits, or what happens when no invites exist. The description is too minimal to provide meaningful transparency beyond the basic action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single, clear sentence with no redundant information. It is appropriately sized and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

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

  For a simple read-only tool with one schema-documented parameter, the description conveys the core purpose. However, it omits useful context such as permission requirements, whether the list is paginated, or the structure of returned invite links. Given no output schema, these omissions leave the description minimally viable but incomplete.

  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 single parameter guildId is fully documented in the schema with a description that mirrors the tool description. The tool description adds no additional semantic detail beyond what the schema already provides, so the baseline score of 3 applies.

  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 specifies the action (取得します - retrieves), the resource (招待リンク一覧 - invite link list), and scope (特定のDiscordサーバー - specific Discord server). This distinguishes it from sibling tools like get_channel_invites, which target a different scope.

  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 by stating it's for a specific server's invites, which suggests it's appropriate when working with server-level invites. However, it does not explicitly mention when to prefer this over get_channel_invites or provide any exclusions or prerequisites.

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

• get_pinned_messagesA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description must carry the full burden of behavioral disclosure. However, it essentially restates the tool name and provides no additional context about required permissions, rate limits, return format, or ordering of results. This is a minimal rephrasing rather than meaningful 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, clear sentence in Japanese that front-loads the action and resource. It is appropriately sized with no redundant words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

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

  This is a simple one-parameter tool with no output schema. The description adequately states the action but does not specify the return structure or note any dependencies on existing context (e.g., requiring access to the channel). For a straightforward list retrieval, this is marginally adequate but not fully 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?

  The schema covers 100% of the parameter (channelId) with a description identical in meaning to the tool description. The description adds no further semantic value beyond what the schema already provides, 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 uses a specific verb '取得する' (retrieve) and explicitly names the resource: a list of pinned messages for a specific Discord channel. This clearly distinguishes it from sibling tools like get_channel_messages, which retrieve regular messages.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

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

  The description implies use when needing pinned messages for a channel but does not explicitly mention when not to use it or compare it to alternatives such as get_channel_messages. No exclusions are given, but the context is clear.

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

• get_webhookA
  3.5/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 that it gets details, without mentioning required permissions, error behavior (e.g., 404 if not found), or the content of the response. This is a minimal disclosure that adds little beyond the tool's name.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single, concise sentence that front-loads the action (get) and target (specific Discord webhook). It contains no filler or redundant information, earning its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

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

  The tool is simple with one parameter fully described in the schema, but there is no output schema and the description does not explain what 'detailed information' includes. It vaguely describes the return value, leaving a gap in completeness for users who need to know what fields to expect.

  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 provides a description for webhookId ('ID of the webhook to get details for'), achieving 100% schema coverage. The tool description adds no additional parameter semantics, so 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.

  Purpose5/5

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

  The description clearly states it retrieves detailed information for a specific Discord Webhook, using the Japanese verb '取得します' (get/retrieve) and the noun '詳細情報' (detailed information). The word '特定の' (specific) distinguishes it from sibling tools like get_guild_webhooks and get_channel_webhooks, which list webhooks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

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

  The description implies the use case: fetch details for a single webhook by ID. However, it does not explicitly mention when to use this tool versus the listing endpoints (get_guild_webhooks, get_channel_webhooks) or provide any exclusion criteria. The guidance is implicit rather than explicit.

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

• delete_webhookA
  3.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 mentions the permission requirement but omits critical details such as the permanent/irreversible nature of deletion, potential side effects, or expected response. For a destructive operation, 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, concise sentence in Japanese that front-loads the action and includes the key permission condition. Every word earns its place, and there is no 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?

  This is a mutation tool with no annotations and no output schema. The description does not explain return values, error handling, or confirm the deletion's permanence. Given the potential consequences of deleting a webhook, the description is incomplete for an agent to fully understand the operation's implications.

  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% (both webhookId and reason have descriptions). The tool description does not add additional parameter context beyond the schema, so the baseline score of 3 applies. No need for further elaboration given the schema's completeness.

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

  Purpose5/5

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

  The description clearly states the action ('Deletes a Discord webhook') and specifies the resource. It distinguishes from sibling tools by the verb 'delete', contrasting with create, update, execute, and get webhook tools. The permission condition adds clarity without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

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

  The description implies the use case: when you need to remove a webhook and have appropriate permissions. It does not explicitly enumerate alternatives or exclusion criteria, but the context is clear given the tool name and sibling set. The permission prerequisite is a form of contextual guidance.

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

• get_guild_webhooksA
  3.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 full responsibility. It only states 'get a list' without disclosing read-only status, permission requirements (e.g., Manage Webhooks), pagination behavior, or response format. This is insufficient for a tool with no annotation safety signals.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  A single concise sentence in Japanese, front-loaded with the action and resource. No filler or redundant information, making it efficient and clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

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

  For a simple one-parameter tool with no output schema, the description sufficiently conveys the operation. The term '一覧' implies a list of all webhooks in the guild, which is complete enough for an agent to understand the tool's scope. Minor gap: no detail on response structure, but not critical at this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

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

  Schema coverage is 100% with guildId described as 'Webhook一覧を取得するサーバーのID'. The description adds no further semantic detail beyond what the schema already provides. Baseline 3 is appropriate as no additional value is contributed.

  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 '特定のDiscordサーバーのWebhook一覧を取得します' uses a specific verb '取得' and resource 'Webhook一覧', clearly indicating a server-scoped list operation. It distinguishes from sibling tools like get_channel_webhooks (channel-scoped) and get_webhook (single webhook) by explicitly scoping to a guild.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

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

  Usage is implied by the phrasing 'a specific Discord server', but no explicit when-to-use or alternatives are mentioned. The tool does not contrast itself with get_channel_webhooks or get_webhook, leaving some ambiguity for an agent deciding between server-level and channel-level webhook queries.

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

• get_server_listA
  3.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 full burden for behavioral disclosure. It only states the primary action and does not disclose any additional behavior like output format, pagination, permission requirements, or effects of the includeDetails parameter. The absence of any such detail makes it below average.

  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. There is no redundancy or filler, and the key information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

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

  For a simple list retrieval tool with one optional boolean parameter and no output schema, the minimal description is mostly sufficient. However, it lacks any mention of the response shape or that includeDetails modifies the output, which could help an agent, but the schema and purpose cover the essentials.

  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 already has 100% coverage with a description for the includeDetails parameter. The tool description adds no parameter-specific meaning. Since schema documentation is complete, baseline of 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool fetches a list of Discord servers the bot is participating in, using a specific verb (取得) and resource (Discordサーバーの一覧). This distinguishes it from sibling tools like get_server_details, which is singular and implies a single server's details.

  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 a list of bot-joined servers is needed, but it doesn't explicitly mention when to prefer this over alternatives such as get_server_details or provide any explicit when-not-to-use guidance. It's minimally adequate but lacks clear contextual direction.

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

• get_server_detailsA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It states it retrieves details, which indicates a read-only operation, but it does not disclose potential error behaviors (e.g., 404 if server not found), permission requirements, or rate limits. The safety profile is clear from the 'get' verb, but additional behavioral context is missing.

  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 sentence in Japanese, directly stating the purpose without any filler. It is front-loaded and every word is informative, 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.

  Completeness4/5

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

  For a simple single-parameter getter, the description is sufficient to understand its core functionality. However, without an output schema, it leaves what 'detailed information' includes unspecified. Given the tool's simplicity, this is acceptable but not perfect.

  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 serverId explained as 'ID of the server to retrieve detailed information for'. The description adds no extra meaning beyond the schema, so the baseline score of 3 applies.

  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 '特定のDiscordサーバーの詳細情報を取得します' clearly states the verb (get) and resource (detailed information of a specific Discord server). It is distinct from sibling tools like get_server_list which focuses on the list of servers, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

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

  The description implies use when needing details of a single server, as opposed to get_server_list for all servers, but it does not explicitly state when to use this tool over alternatives. No exclusions or alternative recommendations are provided.

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

• edit_messageA
  3.9/5.0
  Behavior3/5

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

  Since no annotations are provided, the description carries the full burden of behavioral disclosure. It reveals the critical ownership limitation, but does not cover other behavioral aspects such as required permissions, what happens when editing fails, or whether unprovided fields (e.g., embeds) are cleared.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single, concise sentence in Japanese that immediately states the purpose and the key constraint. It contains no superfluous information and is 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?

  For a relatively simple mutation tool with full parameter descriptions, the description gives the essential purpose and a key limitation. However, with no annotations and no output schema, it lacks details on permissions, error behavior, and post-edit consequences, making it adequate but not fully 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?

  The schema provides descriptions for all four parameters (channelId, messageId, content, embeds), achieving 100% schema description coverage. The description adds no extra parameter-level meaning, so the baseline score of 3 applies.

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

  Purpose5/5

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

  The description clearly states the action '編集' (edit) and the resource '既存メッセージ' (existing message). It further specifies the important constraint '自分が送信したメッセージのみ' (only messages sent by yourself), which distinguishes it from sibling tools like send_message and delete_message.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

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

  The description explicitly communicates a key usage restriction: only messages sent by the user can be edited. This gives clear guidance on when the tool is applicable, though it does not explicitly name alternatives or elaborate on error conditions.

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

• delete_messageA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses a key constraint (requires ownership or permissions) but doesn't mention irreversibility or other side effects. The reason parameter hints at audit logging, but the description adds limited 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, focused sentence that front-loads the action and includes a parenthetical condition. It contains no wasted words and is easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

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

  For a simple delete operation with a comprehensive schema and no output schema, the description conveys the purpose and the permission condition. It is complete given the tool's low complexity.

  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 describes all three parameters with 100% coverage, so the description doesn't need to add parameter details. The description itself adds no extra parameter semantics, 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 action ('Deletes a Discord message') and the resource. It distinguishes from sibling tools like send_message and edit_message by specifying deletion, even though it doesn't explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

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

  The description provides a clear context by stating that deletion is allowed for own messages or with appropriate permissions. This implies when the tool can be used, but it doesn't explicitly mention alternatives or when not to use it, so it lacks explicit exclusions.

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

• get_voice_regionsA
  4.2/5.0
  Behavior3/5

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

  The description states it 'gets' a list, implying a read-only operation, but with no annotations, it carries the full burden of behavioral disclosure. It does not mention return format, rate limits, auth requirements, or side-effect-free nature beyond the verb. This leaves clear gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single, compact sentence that directly states the function without any unnecessary words. It is front-loaded and immediately clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

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

  For a zero-parameter tool with no output schema, the description adequately conveys the essential purpose. It lacks details about the structure of the returned voice regions (e.g., IDs, names), but this is not critical for such a simple listing tool. The description is complete enough for an agent to know when and how to invoke it.

  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 schema confirms this with an empty properties object. Per the rubric, 0 parameters yields a baseline of 4; the description does not need to explain parameter semantics since none exist.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: retrieving the list of available Discord voice regions. It uses a specific verb ('取得') and resource ('ボイスリージョン一覧'), which distinguishes it from sibling tools targeting messages, servers, channels, users, roles, and webhooks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

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

  The context is obvious: this tool is used when you need voice regions. There is no alternate tool for voice regions among siblings, so no exclusions are needed. However, the description does not explicitly mention when not to use it or name alternatives, preventing a perfect score.

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