discord-mcp

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

Annotations already signal this is a write operation (readOnlyHint=false, destructiveHint=false), so the bar for extra behavioral context is lower. The description adds meaningful details: the 2,000-emoji quota, optional application_id behavior, upload format/size limits, recommended dimensions, and a return shape. These go beyond the annotation set without contradicting it.

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

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

The description is well-structured with Markdown headers and bullets, front-loads the purpose, and keeps every section informative. The quota, constraints, example, and return format each serve a distinct purpose with no redundancy or filler.

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

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

For a create tool with three parameters, two required, the description covers all necessary context: scope, alternatives, constraints, optional parameter semantics, and return values. The presence of an output schema means return details need not be exhaustive, but the description still includes a concise return shape.

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

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

The schema already provides 100% parameter description coverage, giving a baseline of 3. The description adds value by explaining the behavior of application_id ('omit to register it on the authenticated bot application'), stating that application_id is optional for the current bot, and giving a concrete example payload.

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

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

The description opens with a specific verb and resource: 'Upload a new application-scoped custom emoji.' It clearly distinguishes this tool from the sibling emojis_create by emphasizing application scope rather than guild scope, and from the other app_emojis_* siblings by positioning this as the create operation.

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

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

The description provides an explicit 'When to use' section, explains that omitting application_id targets the authenticated bot application, and an explicit 'When NOT to use' section that routes guild-only emoji creation to emojis_create. This is unambiguous decision guidance.

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

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

Beyond annotations, the description discloses that deletion is irreversible, requires __confirm:true, depends on MCP_DRY_RUN=false, and returns the deleted object. This gives the agent the operational safety context needed to invoke destructive behavior correctly.

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

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

The description is well-structured with bolded section headers and bullet points, making it scannable. Every sentence serves a purpose, and the critical destructive warning is front-loaded.

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

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

For a destructive 3-parameter tool with output schema, annotations, and sibling context, the description covers purpose, usage boundaries, confirmation flow, and return shape. Nothing essential is missing for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds useful context about omitting application_id to target the authenticated bot application and reiterates the confirmation requirement, but it does not need to add much more.

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

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

Description opens with a specific verb and resource: 'Delete an application emoji.' It distinguishes itself from the sibling tool emojis_delete by explicitly scoping to application emoji versus guild emoji. The destructive nature is highlighted immediately.

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

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

Provides explicit 'When to use' and 'When NOT to use' sections. Names the alternative tool emojis_delete for guild emoji, which removes ambiguity for an agent selecting the correct endpoint.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description only needs to add context. It adds the default application_id behavior and the return shape, giving useful beyond-annotation detail without contradicting annotations.

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

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

The description is compact, clearly sectioned, and front-loads the purpose. Every sentence adds value, and the returns line is short and precise.

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

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

For a simple read-only fetch with only two parameters, a complete output schema, and rich annotations, the description covers purpose, when to use, default behavior, and return fields. Nothing essential is missing.

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

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

The input schema already covers both parameters with descriptions. The description adds meaningful nuance for application_id ('omit to inspect the authenticated bot's application'), but emoji_id semantics are fully covered by the schema. Baseline 3 is appropriate for high schema coverage.

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

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

The description states a specific verb and resource: 'Fetch a single application emoji.' It clearly distinguishes the tool from app_emojis list/create/modify/delete by focusing on single-resource retrieval, though it does not explicitly name the sibling it competes with.

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

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

The 'When to use' section gives concrete use cases: verify an app emoji exists and inspect name/animated flag. It also clarifies the optional application_id behavior. It does not explicitly mention when not to use it versus alternatives, but the guidance is clear enough for selection.

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

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

Annotations already mark this as read-only, idempotent, non-destructive, and open-world. The description adds useful behavioral context beyond those annotations: the per-app scope, the 2,000-item ceiling, and the return shape. This gives the agent a solid mental model of what to expect without contradicting any annotation.

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

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

The description is well-structured with bolded sections for purpose, usage, non-usage, and return value. Every section earns its place, and the most important scoping information is front-loaded. There is minimal redundancy and no filler.

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

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

For a tool with one optional parameter and strong annotations, the description is complete: it covers scope, constraints, default behavior, the key alternative, and the return structure. Nothing essential is missing for an agent to select and invoke the tool correctly.

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

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

Schema coverage for the single parameter is 100%, and the parameter description already states that application_id is the owning app and that omitting it uses the authenticated bot application. The tool description mostly restates this same guidance, so it adds little semantic value beyond the schema.

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

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

The description opens with a specific verb and resource: 'List custom emojis registered against the application,' and immediately clarifies the scope as 'per-app, not per-guild' with a 2,000 limit. This clearly distinguishes it from sibling tools like emojis_list_guild and other emoji mutation tools.

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

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

The description explicitly states when to use the tool: to inspect app-level emojis usable from any guild, and when not to use it: guild-scoped emojis should go to emojis_list_guild. It also explains the optional application_id behavior for the authenticated bot, leaving no ambiguity about selection.

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

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

Annotations already establish write, non-destructive, idempotent behavior; the description adds the key constraint that emoji image bytes cannot be edited and outlines the replacement workflow. It also states the return shape. It does not cover edge cases like rate limits or permission requirements, but annotations cover the main safety profile.

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

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

The description is organized into Purpose, When to use, When NOT to use, and Returns sections with no filler. Every sentence contributes routing or behavioral information.

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

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

For a tool with full schema coverage, an output schema, and rich annotations, the description provides the necessary operation scope, the main limitation (no byte editing), and the replacement path. It is sufficient for an agent to call the tool correctly, though it does not discuss authorization or error conditions.

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

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

The schema covers 100% of parameters with descriptions and validation patterns. The description adds no significant parameter semantics beyond the schema; it restates the `application_id` default behavior already present in the schema. Baseline 3 is appropriate.

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

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

The description opens with a clear verb+resource: 'Rename an application emoji.' This distinguishes it from the guild-oriented sibling `emojis_modify` and identifies the exact operation in one sentence.

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

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

It provides explicit 'When to use' bullets, including the optional `application_id` behavior, and a 'When NOT to use' bullet that names `app_emojis_create` and `app_emojis_delete` as alternatives for byte replacement. An agent can route correctly without inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, signaling a safe read operation. The description adds valuable context beyond annotations by noting the raw path workaround due to missing library types and explicitly listing the return fields. This gives the agent a solid behavioral model without contradicting the annotations.

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

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

The description is extremely concise and well-structured with clear sections: Purpose, Note, and Returns. Every sentence earns its place, providing essential information without any fluff or redundancy.

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

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

The tool has a simple input schema (2 params), output schema present, and annotations cover safety. The description explains the purpose, the API path workaround, and return shape, making it complete for an agent to understand what this tool does and what it returns without ambiguity.

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

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

Schema description coverage is 100%, with both parameters documented (application_id pattern and instance_id max length/description). The description doesn't add extra parameter semantics beyond what's already in the schema, 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.

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

The description states the specific action: 'Fetch a running Activity instance by id' and explicitly mentions the Discord Activities API. This uniquely identifies the tool's purpose and clearly distinguishes it from the many sibling tools by resource type ('Activity instance').

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

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

The description makes it clear this tool is for fetching an activity instance by ID, providing direct context for when it would be used. It doesn't explicitly mention alternatives or when not to use it, but given there are no similar sibling tools for activity instances, the context is clear enough.

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

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

Annotations already declare the tool safe (readOnlyHint, idempotentHint, destructiveHint false), lowering the bar. The description adds valuable behavior details about the return value: it's a 'projected application shape', `name` and `description` remain raw author data, and `untrusted_text` is a separately fenced copy. This goes beyond annotations and helps the agent interpret results.

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

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

The description is tightly structured with bolded headers ('Purpose', 'When to use', 'Returns') and is only three sentences long. Every sentence provides necessary information with no wasted words.

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

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

Given the tool's simplicity (no params, rich annotations, presence of an output schema), the description is complete. It covers what the tool does, when to use it, and what to expect in the return value, without needing to explain structured fields already present in the schema.

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

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

With zero parameters, the baseline is 4. The description mentions the endpoint `/applications/@me`, confirming there are no user-supplied arguments. No additional parameter documentation is needed.

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

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

The description uses a specific verb ('Fetch') and resource ('bot/app application object') with the exact endpoint (`/applications/@me`), making the tool's function crystal clear. It also distinguishes itself from sibling tools like `application_modify_current` and `application_get_role_connection_metadata` by focusing on the current application object.

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

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

The description provides an explicit 'When to use' section listing concrete use cases (confirm app identity, read flags, install URLs, tags, interaction endpoint). It lacks explicit exclusions or named alternatives, but the context is clear enough for an agent to decide when this tool is appropriate.

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

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

The annotations already declare readOnlyHint true and destructiveHint false, and the description complements this by detailing the return shape `{records, count}` and the enum range. This adds behavioral context without contradicting the annotations.

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

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

The description is two labeled lines, front-loading the purpose and then the return structure. No wasted words.

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

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

For a single-parameter list operation with rich annotations and output schema, the description covers the purpose and return shape sufficiently. It doesn't discuss pagination or edge cases, but these are not necessary given the simplicity.

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

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

The input schema already documents `application_id` with description and pattern, and the description adds no further parametric information. Since schema coverage is 100%, the description provides no extra semantic value.

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

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

The description uses 'List' as a specific verb and identifies the resource as 'application role-connection metadata records', clearly distinguishing this from the modify sibling. The parenthetical adds context about linked roles criteria.

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

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

The description implies its usage through the 'List' verb but does not explicitly state when to use it over siblings or exclude alternatives. There is no mention of the modify counterpart or any condition-based guidance.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true, and the description adds that name/description remain raw while untrusted_text provides a separately fenced copy, which is useful behavioral context beyond annotations. No contradiction.

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

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

The description is concise and front-loaded with purpose, followed by a brief usage instruction and return summary. No filler, each sentence adds value.

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

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

While the output schema provides return structure and annotations cover safety, the description leaves many parameters unexplained and lacks details about field constraints or side effects. It covers core behavior but is incomplete for a 13-parameter mutation tool.

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

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

Schema description coverage is only 8%, and the description does not explain the meaning or usage of most parameters (tags, install_params, integration_types_config, etc.). It only mentions the return fields and generic partial-update guidance, so agents lack necessary semantic detail for correct invocation.

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

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

Description clearly states 'Edit the bot/app application object (PATCH /applications/@me)' with a specific verb and resource, distinguishing it from siblings like application_get_current and application_modify_role_connection_metadata.

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

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

Provides explicit instruction to pass only fields to change and notes all fields optional, guiding usage. However, it does not explicitly contrast with alternative tools or state when not to use it.

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

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

Beyond the annotations (readOnlyHint false, destructiveHint false), the description adds key behavioral context: this is a wholesale replace, records are removed, and it returns '{records, count}'. This fully informs the agent of the side effects and result shape, exceeding what annotations alone provide.

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

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

Three bolded sections in under 25 words: purpose, behavior warning, and return value. Each sentence earns its place, front-loaded with the core purpose, and there is no fluff.

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

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

The description covers the essential behavioral aspects (replace, removal, max 5, return shape) and the schema covers parameter details. It doesn't mention permissions or auth requirements, but for a two-parameter tool with a well-specified schema, it is nearly complete. The output schema signal also reduces the need to explain return values.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds the 'wholesale replace' context but doesn't elaborate on individual parameters beyond what the schema already describes. It does reinforce that `records` is the replacement set, adding minor value.

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

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

The description opens with 'Replace the application role-connection metadata records' – a clear verb and resource. It further specifies a 'wholesale replace' semantics, distinguishing it from get/partial-update operations and aligning with the sibling tool application_get_role_connection_metadata.

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

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

The description clearly warns that 'any existing record not in records is removed', which is critical usage guidance for preserving existing entries. It does not name alternative tools explicitly, but the replace-vs-get distinction is clear and the behavior is unambiguous.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior, and the description adds useful context beyond them: pagination via the `before`/`oldest_id` relationship, descending ID ordering, and the note that `reason` values are raw moderator-controlled data. It stops short of covering rate limits or permission requirements, but the safety profile is already well established.

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

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

The description is well-structured with bold headers and is free of filler. Purpose, usage context, example, pagination, and return contract are each one concise section, making it easy for an agent to parse quickly and call the tool correctly.

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

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

Given the rich schema, annotations, and output schema, the description covers the essential operational details: purpose, when to use, concrete example, pagination behavior, and return shape. It could mention the 'View Audit Log' permission requirement, but that is a minor gap for a read-only call.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds a concrete example mapping `action_type:20` to MEMBER_KICK and explains how the `before` parameter connects to the return field `oldest_id`, which is more meaningful than the schema's generic 'ID less than' description.

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

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

The description explicitly states 'Fetch audit log entries for a guild' with a specific verb and resource. This distinguishes it from all sibling tools, none of which target audit logs, and the 'when to use' examples reinforce its unique forensic purpose.

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

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

A dedicated 'When to use' section gives clear investigative use cases like 'who kicked X?' and post-incident forensics. It does not explicitly mention when not to use the tool or name alternatives, but the context is strong enough for an agent to select it appropriately.

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

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

Annotations already denote a non-read-only mutation and non-destructive behavior. The description adds valuable behavioral context by detailing the conditional dependency of trigger_metadata on trigger_type (e.g., '1 KEYWORD → keyword_filter, regex_patterns, allow_list') and specifying the return shape. This goes beyond the annotations without contradicting them.

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

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

The description is well-structured with bold headers, bullet points, and a clear returns line. It is concise—every sentence provides necessary information without repetition or fluff. The conditional mapping is presented compactly and is easy to scan.

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

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

For a tool with 10 parameters, nested objects, and complex conditional logic, the description covers purpose, usage, conditional metadata, and return value. It is complemented by full schema documentation, making it comprehensive. No critical missing context (e.g., permissions, errors) is apparent for the agent to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra value by mapping each trigger_type to the applicable trigger_metadata fields, which is not explicitly enumerated in the schema comments. This helps the agent decide which combinations to use, exceeding the bare schema descriptions.

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

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

The description opens with 'Purpose: Create an AutoMod rule', which is a clear verb+resource statement. It distinguishes this tool from siblings like automod_modify_rule, automod_get_rule, automod_delete_rule, and automod_list_rules by explicitly focusing on creation.

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

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

The 'When to use' section provides concrete examples (keyword filter, spam blocker, mention-raid guard) indicating the tool's intended scenarios. However, it does not explicitly mention alternatives or when not to use, but the context of sibling tool names offers enough differentiation.

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

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

Annotations already indicate destructiveHint=true, but the description goes further by stating the operation is irreversible, requiring __confirm:true and MCP_DRY_RUN=false for actual deletion, and specifying the return payload. This adds critical safety context beyond the annotations.

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

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

The description is well-structured with bolded labels, front-loaded purpose, and every sentence contributes meaning. It is compact yet comprehensive—five short sections covering purpose, usage, return, and security in fewer than 100 words.

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

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

For a destructive operation, the description covers all key aspects: purpose, alternative, irreversibility, confirmation mechanism, return format, and dry-run behavior. The sibling list and schema enrich the context further, making this fully self-contained for safe invocation.

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

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

Schema coverage is 100%, so the schema fully documents each parameter. The description adds value by explaining the purpose and triggering mechanism of __confirm, which is not obvious from the schema alone. It does not describe audit_reason, but the schema already covers it.

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

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

The description opens with a specific verb and resource: 'Delete an AutoMod rule.' It immediately flags 'DESTRUCTIVE - IRREVERSIBLE' and distinguishes from the sibling tool automod_modify_rule by explaining when to use the alternative. This makes the tool's purpose unambiguous and well-scoped.

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

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

Provides explicit 'When to use' and 'When NOT to use' sections, including a concrete alternative (automod_modify_rule with enabled:false) for temporary disabling. This is model behavior for guiding tool selection.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context about the return payload: 'name and trigger metadata remain raw user-authored data; untrusted_text provides a separately fenced copy.' This discloses data fidelity nuances beyond the safety annotations and helps the agent interpret results correctly.

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

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

The description is compact and well-structured with 'Purpose', 'When to use', and 'Returns' sections. It front-loads the core purpose and contains no redundant phrasing. Every sentence serves a functional role and the overall length is appropriate.

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

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

For a simple read operation with two well-documented parameters, an output schema, and strong annotations, the description covers all essential aspects: purpose, usage, and return shape nuances. It does not need to elaborate on return values beyond the note about raw data and untrusted_text, since an output schema exists.

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

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

Schema description coverage is 100%, with both guild_id and rule_id having clear descriptions in the input schema. The tool description adds no extra parameter details, so it does not improve on the schema. Baseline 3 is appropriate given high schema coverage.

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

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

The description explicitly states 'Fetch a single AutoMod rule' with a specific verb and resource, distinguishing it from sibling tools like automod_list_rules, automod_modify_rule, automod_create_rule, and automod_delete_rule. The purpose is unambiguous and precisely scoped to a single rule retrieval.

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

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

The description provides a clear usage context: 'Inspect rule config before editing.' This implies a specific workflow and aligns with the sibling automod_modify_rule tool. However, it does not explicitly mention alternatives or when not to use, so it lacks full exclusionary guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context about the return format and a warning that rule names remain raw user-authored data, with untrusted_names fenced separately. This is useful beyond annotations.

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

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

The description is well-structured with clear Purpose, When to use, and Returns sections. Every sentence provides value, and there is no fluff or repetition.

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

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

This is a simple read-only tool with one parameter and an output schema. The description includes the return shape and context about untrusted names, making it complete for the tool's complexity.

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

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

Schema coverage is 100% with the single guild_id parameter already described. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline 3 applies.

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

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

The description states 'List all AutoMod rules in a guild' with a specific verb and resource, clearly distinguishing it from sibling tools like automod_get_rule (single rule) and automod_create_rule (write operation).

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

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

The 'When to use' section provides clear context: audit existing rules and find a rule ID before modifying/deleting. It implies alternatives (modify/delete tools) but does not explicitly name them or state when not to use.

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

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

Annotations already indicate readOnly=false, destructive=false, idempotent=true. The description adds valuable context beyond annotations: patch semantics (only provided fields are updated), immutability of trigger_type, and the return object shape. It does not mention permissions or rate limits, but the annotation coverage plus these extras are strong.

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

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

The description is compact, uses clear bold headers, and front-loads the purpose. The bulleted usage list and note are easy to scan, with no filler or redundant information.

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

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

The description covers purpose, patch semantics, an important immutable constraint, and return shape. With the output schema present, this is sufficient for an agent to select and invoke the tool. It does not elaborate on parameter interdependencies (e.g., trigger_metadata fields valid per trigger_type), but the schema's nested descriptions partly cover that.

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

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

Schema description coverage is only 50%, and the description mentions only 'keyword list, actions, enabled' as examples, leaving other parameters (exempt_roles, exempt_channels, trigger_metadata, audit_reason) implied. It does add the critical patch semantics ('Pass only fields you want to change'), but it does not fully compensate for the schema's incomplete parameter descriptions.

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

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

The description states 'Update an AutoMod rule's settings' with a specific verb and resource, and clarifies partial-update behavior with 'Pass only fields you want to change.' This clearly distinguishes it from sibling tools like automod_create_rule, automod_delete_rule, automod_get_rule, and automod_list_rules.

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

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

The description includes a dedicated 'When to use' section listing concrete scenarios (tweak keyword list, change actions, toggle enabled). It also provides an explicit alternative for the immutable trigger_type field: 'delete and recreate.' This gives clear guidance on when to use this tool versus alternatives.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the description doesn't need to restate that this is a write operation. The description adds valuable behavioral context beyond annotations: 'Pick fields that match the type - extra fields are ignored by Discord' and a concrete example illustrating usage. It stops short of describing permission requirements or failure modes, but with annotation coverage this is sufficient.

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

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

The description is compact yet well-structured, using bolded mini-headings (Purpose, When to use, When NOT to use, Type values, Example, Returns). Every sentence serves a purpose: defining scope, giving usage context, listing type enums, demonstrating usage, and summarizing output. No filler or redundancy.

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

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

For a tool with 19 parameters, nested objects, and an output schema, the description provides comprehensive context: purpose, type values, exclusions, an example, and a return summary. It fully addresses the agent's need to decide when and how to use the tool, with the schema handling detailed parameter semantics. No significant gaps remain for effective invocation.

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

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

Schema coverage is 100%, which sets a baseline of 3. The description goes beyond the schema by explaining Discord channel type values (0-16), noting that type-specific fields should be chosen and extra fields are ignored, and providing an example that ties guild_id, name, type, and parent_id together. This adds meaning beyond raw schema definitions, though it doesn't elaborate on every parameter.

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

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

The description opens with 'Create a new channel in a guild (text, voice, category, announcement, forum, etc.)', which is a specific verb+resource that immediately conveys the tool's function. It also distinguishes from thread creation by explicitly referencing alternative tools for threads, making its scope clear relative to siblings.

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

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

Provides explicit when-to-use guidance ('Programmatic guild bootstrap; tier-based channel provisioning') and a clear when-NOT-to-use with named alternatives ('Threads - use `messages_create_thread`, `channels_forum_create_thread`, or thread-specific tools'). This is precisely the kind of contextual guidance that helps an agent select the right tool.

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

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

Beyond the destructiveHint annotation, the description adds crucial behavioral context: irreversibility, the ConfirmRequired gate, the __confirm:true requirement, and the MCP_DRY_RUN=false condition for actual deletion. It also states the return shape. This enriches what annotations already convey without contradicting them.

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

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

The description is well-structured with clear headings (Purpose, When to use, When NOT to use, Returns, Security) and every line adds value. It is compact for a destructive tool and front-loads the critical warning.

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

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

Given the presence of an output schema, comprehensive annotations, and sibling context, the description still supplies the necessary operational details: the destructive confirmation flow, dry-run behavior, return value, and an explicit alternative. This is complete for a high-risk mutation tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description only reiterates the __confirm behavior that the schema already documents; it adds no new parameter-level semantics. It does not explain audit_reason beyond the schema.

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

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

The description opens with a specific verb+resource pair: 'Delete a channel (or close a DM).' It is immediately distinguishable from siblings like channels_modify and channels_delete_permissions because it names the destructive action and notes the alternative for permission hiding.

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

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

Contains an explicit 'When to use' section ('tear down stale or compromised channels') and a 'When NOT to use' section that names the exact alternative tool (channels_modify_permissions). This is exactly the kind of decision guidance the rubric calls for.

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

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

The description adds behavioral context beyond the annotations: it explains the return format (`{deleted, channel_id, overwrite_id}`) and the idempotent behavior of treating non-existent overwrites as success, which aligns with `idempotentHint=true`. It does not mention auth requirements, but the annotations already cover safety (`readOnlyHint=false`, `destructiveHint=false`). No contradiction found.

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

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

The description is well-structured with clear sections (Purpose, When to use, When NOT to use, Returns) and every sentence provides necessary information without redundancy. It is concise and front-loaded with the main purpose.

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

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

For a relatively simple delete operation, the description covers purpose, usage boundaries, return behavior, and edge-case handling. The input schema is fully documented, and the output schema exists. The description is complete enough for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add significant new meaning to the parameters beyond the schema, though the return format indirectly clarifies `channel_id` and `overwrite_id`. This is acceptable given the schema's completeness.

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

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

The description clearly states the action: 'Remove a permission overwrite from a channel.' It uses a specific verb and resource, and the 'When NOT to use' section explicitly distinguishes it from the sibling tool `channels_modify_permissions`, so there is no ambiguity about its purpose.

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

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

The description provides explicit when-to-use guidance ('Revert a channel back to inheriting role/category defaults') and when-not-to-use guidance ('Changing allow/deny bits → use `channels_modify_permissions`'), including a named alternative. This fully clarifies usage context.

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

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

Annotations already mark readOnlyHint=false and destructiveHint=false. The description adds behavioral context by disclosing that a delivery webhook is auto-created on the target and that Discord rejects non-announcement channels. This goes beyond the annotations without contradicting them.

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

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

The description is concise, well-structured with clear labels (Purpose, When to use, When NOT to use, Returns), and avoids any redundant filler. Every sentence adds information.

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

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

With an output schema present and annotations covering key behavioral flags, the description sufficiently covers purpose, usage conditions, return value, and a critical constraint. It could mention permissions or rate limits, but these are not essential given the existing structured data.

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

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

Schema coverage is 100% and each parameter already has a meaningful description (channel_id as source, webhook_channel_id as target, audit_reason as audit log reason). The tool description does not add further parameter-level detail beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description states 'Cross-post messages from an announcement (news) channel into a target channel via a webhook,' which uses a specific verb, resource, and mechanism. This clearly distinguishes it from sibling tools like messages_crosspost or webhooks_create.

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

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

The description includes explicit 'When to use' and 'When NOT to use' sections, with a concrete use case (mirroring release announcements) and a rejection condition (source not type 5). It does not explicitly name alternative tools, so it misses the full 5 criterion, but the guidance is clear and actionable.

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

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

Annotations already indicate non-read-only, non-idempotent, non-destructive behavior. The description adds useful behavioral constraints beyond annotations: the nested message requirement, the content/embed/component condition, and the 'Plain text channels - Discord rejects' caveat. It does not contradict annotations.

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

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

The description is well-structured with bolded section labels, concise bullet points, and no filler. Every sentence contributes actionable information, keeping the length appropriate for the tool's complexity.

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

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

For a tool with 7 parameters and a nested message object, the description covers purpose, when/when-not, body shape requirements, and return shape. It provides sufficient context for an agent to select and invoke the tool correctly, complementing the rich schema and output schema.

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

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

Schema coverage is high (86%), and the schema already documents the key parameters including message's requirement for content/embeds/components. The description reinforces the nested body shape but does not add significant meaning beyond what the schema provides. Some parameters like rate_limit_per_user lack detail, but the description does not compensate for that.

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

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

The description opens with a specific verb-object statement: 'Create a new forum (or media) thread with an initial message in one request.' This clearly identifies the tool's unique scope and differentiates it from the sibling messages_create_thread by explicitly calling out the alternative.

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

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

Provides explicit 'When to use' and 'When NOT to use' sections. It names the alternative tool (messages_create_thread) for anchored threads and states that plain text channels are rejected, giving an agent clear decision criteria.

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

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

While annotations already declare readOnlyHint=true and idempotentHint=true, the description adds valuable behavioral details: name is null for DMs, position/parent_id are absent for threads and DMs, and topic is raw user-controlled data that is fenced in text responses. These edge cases go beyond the annotations and help the agent predict response variations.

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

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

The description is compact and well-organized with bold section headers (Purpose, When to use, Returns). Every sentence adds useful information, and the return format is presented clearly without fluff. It is front-loaded and scannable.

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

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

Given the tool's simplicity, the presence of an output schema, and strong annotations, the description is complete. It explains not only what the tool returns but also the conditional presence of fields and the handling of raw topic data, covering potential edge cases an agent would need.

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

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

The schema has full description coverage for channel_id ('Target channel ID'), and the parameter is a simple ID. The description does not add extra meaning about the parameter itself, but none is needed given the schema coverage and simplicity. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Fetch full metadata for a single Discord channel.' It clearly distinguishes from siblings like channels_list (plural listing) and messages_get (messages), and the emphasis on 'single' narrows the operation scope.

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

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

The 'When to use' section explicitly identifies the context: 'inspect topic, slowmode, nsfw of a known channel.' This gives clear context for when the tool is appropriate, but it does not explicitly mention when not to use it or name alternative tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scope ('all channels') and return format, but the return format is also present in the output schema, so it adds limited extra behavioral context beyond the annotations.

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

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

The description is compact and well-organized with bold section labels for Purpose, When to use, Example, and Returns. Every sentence is purposeful and there is no filler or redundancy.

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

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

For a simple read-only tool with one parameter and an output schema, the description covers purpose, usage, example, and return shape. It is fully sufficient for an AI agent to select and invoke the tool correctly.

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

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

The input schema already provides a full description for guild_id with 100% coverage. The description includes an example value but not additional semantic detail beyond what the schema already offers, so it does not raise the baseline.

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

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

The description clearly states 'List all channels in a Discord guild' using a specific verb and resource. This distinguishes it from sibling tools like channels_get, which retrieves a single channel, and channels_list_active_threads_guild, which lists threads.

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

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

It provides explicit use cases: 'discover channel IDs by name; audit channel layout'. This gives clear context for when to use the tool, though it does not explicitly name alternative tools or state when not to use it.

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

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

Even with annotations indicating read-only, idempotent, and non-destructive behavior, the description adds meaningful context: the bot's visibility limitation, the return structure, and the note about raw Discord data vs. fenced human-readable text. This goes beyond annotation hints.

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

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

The description is compact and well-structured using bold headers (Purpose, When to use, When NOT to use, Returns). Every sentence conveys necessary information without redundancy.

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

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

Given the single parameter, supportive annotations, and presence of an output schema, the description fully covers purpose, usage, exclusions, and return behavior. No critical gaps remain for an agent to invoke it correctly.

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

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

The input schema already provides 100% coverage with a description for guild_id. The tool description does not add further parameter-level detail, so the baseline of 3 for high schema coverage applies.

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

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

The purpose is clearly stated with a specific verb and scope: 'List every active thread the bot can see across an entire guild.' This distinguishes it from sibling thread-list tools by emphasizing the guild-wide scope and active-thread filtering.

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

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

Provides explicit 'When to use' and 'When NOT to use' sections, naming alternative tools (channels_list_public_archived_threads / channels_list_private_archived_threads) for excluded cases. This gives the agent clear decision criteria.

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

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

The description adds context beyond the annotations by specifying bot-user scoping, the return shape `{threads, has_more, count, channel_id}`, and a note about raw Discord data versus the human-readable response. No contradictions with the annotations (readOnlyHint, idempotentHint, etc.) are present.

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

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

The description is well-structured with bold section headers, concise bullet points, and no filler. Each sentence earns its place, covering purpose, usage, alternatives, and return format efficiently.

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

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

Given the read-only, idempotent nature (annotations), comprehensive schema parameter descriptions, and an output schema, the description is complete. It covers the tool's specific scope, how to distinguish it from alternatives, and the expected response format, which is sufficient for an agent to select and invoke the tool properly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add extra parameter semantics beyond what the schema provides; it only reinforces the return shape, which is already implied by the schema. The parameter details (limit, before, channel_id) are fully documented in the schema.

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

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

The description clearly states the tool lists private archived threads joined by the current bot user under a parent channel, using the specific verb 'list' and a specific resource. It distinguishes itself from the sibling `channels_list_private_archived_threads` by emphasizing the 'current bot user' scope.

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

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

Explicit 'When to use' and 'When NOT to use' sections provide clear guidance. The description names the alternative tool `channels_list_private_archived_threads` and notes its MANAGE_THREADS permission requirement, making it easy to decide when to use this tool versus others.

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

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the description adds extra value by disclosing the MANAGE_THREADS permission requirement and the output formatting nuance (raw Discord data vs. fenced human-readable text). It doesn't repeat annotation info and adds meaningful 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.

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

The description is well-structured with bold labels, front-loads the purpose, and keeps each section tight. No wasted words; every sentence contributes.

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

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

Given the tool's moderate complexity, the presence of robust annotations and an output schema, this description covers purpose, usage, permissions, and return format. It is complete for an agent to confidently invoke the tool correctly.

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

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

Schema coverage is 100%, so each parameter already has a description. The tool description doesn't add extra parameter meaning beyond what the schema provides, but it also doesn't need to. Baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource: 'List archived private threads under a parent text channel.' It clearly distinguishes this from the sibling tool channels_list_joined_private_archived_threads in the 'When NOT to use' section.

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

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

It explicitly states when to use ('Moderation review of historical private threads') and when NOT to use, naming the alternative tool. This is exactly the kind of guidance that helps an agent select among siblings.

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

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

The description goes well beyond annotations by explaining pagination mechanics (pass `before` and `limit`, use `has_more`) and noting that structured names remain raw Discord data while the human-readable response fences them. This adds meaningful 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.

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

The description is compact and well-structured with labeled sections (Purpose, When to use, Pagination, Returns). Every sentence adds distinct value with no redundancy or filler.

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

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

The description covers purpose, use cases, pagination behavior, and return format. It even includes return details despite an existing output schema, making the tool easy to select and invoke correctly.

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

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

Although the schema already covers all parameters 100%, the description enriches them by clarifying that `before` is derived from a prior `archive_timestamp` and that `has_more` indicates additional pages. This provides practical usage context beyond the schema definitions.

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

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

The description states it 'List archived public threads under a parent text/announcement channel,' which clearly specifies the verb, resource, and scope. This distinguishes it from sibling tools like channels_list_private_archived_threads and channels_list_joined_private_archived_threads.

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

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

It provides explicit use cases: 'Recover stale discussions; audit what was archived.' This gives clear context for when to use the tool, though it doesn't explicitly mention when not to use it or name alternative tools.

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

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

Annotations already include readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds that only provided fields are updated, that Discord ignores non-applicable fields, and the return shape. This extends beyond annotations without contradiction.

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

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

Well-structured with Markdown headers and bullets. Every sentence adds value: purpose, usage, exclusions, field behavior, and return value. No redundant or filler content.

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

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

Given 21 parameters, an output schema, and rich annotations, the description covers the core behavior, usage boundaries, and return value. It lacks permission requirements and error scenarios, but these are not essential for tool selection and invocation.

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

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

Schema description coverage is low (24%), and the description does not individually explain each parameter. However, it does add the crucial general semantics of partial updates and field applicability, which partially compensates for the schema gaps.

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

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

The description clearly states 'Update an existing channel's settings' with a specific verb and resource. It further distinguishes from siblings by explicitly listing 'When NOT to use' with channels_modify_permissions and channels_delete.

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

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

Provides a 'When to use' list of concrete scenarios and a 'When NOT to use' with alternative tool names. Also explains field applicability mirrors channels_create_guild_channel, helping the agent know which params apply.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds useful context by clarifying that the tool replaces existing overwrites, explains the `type` encoding, and discloses the return shape `{updated, channel_id, overwrite_id}`. No contradiction with annotations.

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

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

The description is well-structured with bold labels and bullet points, presenting the purpose, usage guidance, parameter notes, and return value in a compact format. No redundant sentences.

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

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

Given the tool's moderate complexity, the description covers purpose, usage guidelines, parameter semantics, and returns. It also references the sibling delete tool for exclusions. With an output schema present, it does not need to detail return values further; the description is sufficient for an agent to select and invoke the tool.

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

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

The input schema covers all 6 parameters with descriptions, so the baseline is 3. The description adds a concise explanation of `type` (0=role, 1=member) and that `allow`/`deny` are stringified bitfields, but this largely mirrors the schema descriptions. It provides minimal additional semantic value beyond the schema.

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

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

The description states 'Create or replace a permission overwrite for a role or user on a channel' with a specific verb and resource, and clearly distinguishes from `channels_delete_permissions`. It also specifies the scope (role or user) and the action (create/replace).

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

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

It provides explicit 'When to use' examples like restricting a channel to a role or allowing moderators to manage messages, and 'When NOT to use' with a named alternative (`channels_delete_permissions`) for removing overwrites entirely.

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

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

Beyond the annotations (idempotentHint=true), the description explains that repeat calls extend the indicator, adding behavioral nuance. The ~10-second duration and the return shape ({ok, channel_id}) are additional transparency not found in structured data.

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

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

Structured in four short sections, each sentence provides distinct value—purpose, use cases, non-use case, and return info. No filler or redundancy.

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

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

For a low-complexity tool with one parameter, output schema, and full annotations, the description covers all needed context: when to use, what it returns, and idempotency behavior. It is complete.

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

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

The schema already provides a description for channel_id with 100% coverage, and the tool description does not add further detail. Per the baseline for high schema coverage, a 3 is appropriate.

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

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

The description opens with 'Show the bot as typing in a channel for ~10 seconds,' a specific verb+resource statement. It clearly distinguishes from siblings like messages_send by focusing solely on the typing indicator.

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

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

The 'When to use' and 'When NOT to use' sections explicitly state when to invoke this tool (long-running operations) and when not to (replacement for messages). This provides clear guidance relative to sibling messaging tools.

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

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

Beyond the annotations (destructiveHint=true), the description adds critical behavioral details: the atomic wholesale replacement, the deletion of unspecified commands, the empty-array danger, the ConfirmRequired gate, the MCP_DRY_RUN requirement, and the return shape. This fully discloses what gets destroyed and what conditions are needed to apply changes.

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

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

The description is well-structured with bold section headers (Purpose, When to use, Caution, Security, Returns). Every sentence earns its place, covering all essential aspects without redundancy or fluff.

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

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

The description is complete for a destructive bulk operation: it explains the atomic replacement semantics, the use case, the danger of empty arrays, the confirmation/dry-run flow, and the return value. Combined with rich annotations and output schema, it provides all necessary context for correct use.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description repeats __confirm semantics and empty-array behavior already present in the schema, adding no new information about the parameters.

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

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

The description uses the specific verb 'REPLACE' with the resource 'entire global command registry' and clarifies that commands not included are deleted. This clearly distinguishes it from siblings like commands_create_global (single create) and commands_bulk_overwrite_guild (guild-scoped).

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

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

It provides a concrete use case (CI deploy re-sync) and a caution to call commands_list_global first to confirm scope. It does not explicitly list when-not-to-use or name alternative tools, but the context is clear enough for an agent to choose appropriately.

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

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

Beyond the annotations (destructiveHint, idempotentHint), the description reveals critical behavior: any commands not listed are deleted, an empty array deletes every command, the operation is atomic, and it requires __confirm:true combined with MCP_DRY_RUN=false to apply. It also discloses the dry-run preview fallback and the exact return shape. This goes well beyond what annotations provide.

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

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

The description is tightly structured with bold labels (Purpose, Caution, Security, Returns) and every sentence carries meaningful information. It is compact yet complete, front-loading the core purpose and then layering caution and security details. No filler or redundancy exists.

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

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

For a destructive, high-impact bulk operation, the description covers the purpose, safety confirmation, dry-run behavior, and return format. The schema covers all parameters, and the description's caution about confirming scope addresses the main companion tool. Together with annotations, this leaves no significant operational gap.

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

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

The input schema already provides 100% coverage for all four parameters, including descriptions for commands, guild_id, __confirm, and application_id. The description adds no new parameter-level detail beyond what the schema states; it only restates the replace semantics already in the schema's commands description. Baseline 3 applies because the schema does the heavy lifting.

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

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

The description opens with a specific verb and resource: 'Atomically REPLACE the guild-scoped command registry.' It clearly distinguishes from global bulk overwrite and per-command create/modify/delete siblings by emphasizing the guild scope and wholesale replacement semantics.

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

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

The 'Caution' line explicitly instructs to call commands_list_guild first to confirm scope, which is direct guidance for safe usage and names an alternative. It implies when to use this tool (full replacement) but doesn't enumerate all when-not scenarios. This is clear context with one named alternative, short of exhaustive exclusion guidance.

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

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

The description discloses upsert semantics ('posting the same name+type updates the existing command') which goes beyond the idempotentHint annotation. It also reveals propagation delay and type-specific requirements for description, adding behavioral context not visible in annotations.

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

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

The description is clearly structured with bold labels (Purpose, Body, Idempotent, Returns) and each sentence provides distinct information. It is appropriately sized for the tool complexity and front-loads the purpose.

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

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

The description covers the core usage, idempotency, propagation, and return shape, which is substantial given the output schema and annotations exist. However, it does not elaborate on the complex options structure or many optional parameters, leaving some gaps for a 14-parameter tool.

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

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

With only 7% schema description coverage, the description adds meaning for key parameters: `name` is required, `description` is conditionally required based on `type`, and `type` values are mapped to CHAT_INPUT/USER/MESSAGE. However, 11 parameters remain undocumented, so the description only partially compensates for the low schema coverage.

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

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

The description clearly states 'Create or upsert a global application command' with a specific verb and resource. It distinguishes from guild commands by specifying 'global' and mentions the ~1 hour propagation time, which separates it from sibling commands like commands_create_guild.

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

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

The description provides context about global command propagation delay but does not explicitly name alternatives or state when not to use this tool. The 'Idempotent' and propagation notes imply usage considerations, but there is no exclusion such as 'use commands_create_guild for instant propagation.'

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

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

Annotations already cover read-only, destructive, and idempotent hints. The description adds the useful behavioral detail about immediate propagation and lists the return fields. However, it does not disclose permission requirements or the exact semantics of 'upsert' (e.g., whether an existing command is replaced).

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

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

The description is two sentences with clear bold section headers. It front-loads the purpose and returns, with no redundant or filler content.

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

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

Given the tool has 15 parameters and extremely low schema description coverage, this description is too sparse. It provides no guidance on how to structure command options, permissions, or use cases, and the output schema does not compensate for the missing parameter context.

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

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

Schema description coverage is only 13%, and the description adds virtually no parameter-level meaning. It mentions 'guild-scoped' but does not explain the required application_id, guild_id, name, or the many optional fields. The description fails to compensate for the low coverage.

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

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

The description clearly states a specific verb and resource: 'Create or upsert a guild-scoped slash command.' It also distinguishes from the global variant by noting that guild commands propagate immediately, which aligns with the sibling tool commands_create_global.

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

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

The description gives clear context on when to use this tool versus the global alternative by highlighting the propagation timing difference. It does not explicitly exclude other alternatives like bulk overwrite, but the guild-vs-global contrast provides actionable usage guidance.

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

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

Beyond the annotations (destructiveHint, readOnlyHint false), the description discloses the full destructive scope ('removes the command from every guild'), a propagation time ('~1 hour'), and the explicit authorization gate ('Pass __confirm:true AND MCP_DRY_RUN=false to actually delete'). This adds critical safety context that annotations alone do not provide.

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

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

The description is tightly structured into three labeled lines: Purpose, Effect, Returns. Front-loaded with the core action, every sentence adds new information with zero filler. Extremely efficient for a destructive tool.

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

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

Given an output schema (so returns are already specified) and comprehensive annotations, the description still covers the essential safety and execution context: what gets deleted, the propagation delay, and the confirmation/dry-run mechanism. It is complete enough for an agent to use this tool correctly without additional documentation.

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

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

The input schema already describes all three parameters with 100% coverage, including the __confirm confirmation parameter and the MCP_DRY_RUN requirement. The description adds no new parameter-level meaning beyond pointing to __confirm and mentioning the return object, so it meets the baseline but doesn't exceed it.

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

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

The description opens with 'Delete a global application command' – a specific verb ('Delete') and resource ('global application command'), clearly distinguishing it from guild-scoped siblings like commands_delete_guild. The effect statement 'removes the command from every guild within ~1 hour' further removes ambiguity.

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

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

The description implies usage for global commands ('global', 'every guild'), but does not explicitly compare against alternatives such as commands_delete_guild or state when not to use it. Usage is clear enough for an agent familiar with command scoping, but lacks direct exclusion guidance.

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

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

The description goes beyond annotations by explicitly stating 'DESTRUCTIVE - IRREVERSIBLE' and detailing the confirmation mechanism ('Pass __confirm:true AND MCP_DRY_RUN=false'). It also discloses the return format, providing behavioral clarity beyond what readOnlyHint/destructiveHint annotations convey.

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

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

The description is concise, front-loaded with the purpose, and each sentence earns its place. It covers purpose, destructiveness, return value, and confirmation in under three short sentences with no redundancy.

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

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

Given the output schema exists and annotations cover safety, the description is largely complete. It explains the destructive nature, confirmation flag, and return object. However, it omits any mention of required permissions or error cases, which is a minor gap for a mutation tool.

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

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

Schema coverage is 100%, so parameters are already well-documented. The description adds no significant new parameter semantics; it repeats the __confirm behavior already present in the schema. The mention of MCP_DRY_RUN is similarly in the schema, so baseline 3 applies.

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

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

The description states 'Delete a guild-scoped command' with a specific verb and resource, clearly distinguishing it from sibling tools like commands_delete_global. The 'guild-scoped' qualifier removes ambiguity and sets it apart from global command deletion.

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

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

The description implies when to use the tool (for guild-scoped commands) but does not explicitly contrast it with alternatives or provide a 'when-not-to-use' scenario. The destructive warning and confirmation requirement are more about how to invoke than when to choose this tool.

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

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

Annotations already indicate mutation (readOnlyHint: false) and idempotence. The description adds critical behavioral context: user OAuth token is required (not bot token), user must have manage-guild permission, and it returns the updated permission object. This exceeds what annotations alone provide.

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

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

Structured with bold section labels and every sentence earns its place. It covers purpose, auth, body format, and return value in a compact, readable format without unnecessary detail.

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

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

Given that an output schema exists, the description appropriately focuses on the auth caveat, body structure, and expected response. It provides enough information for an agent to invoke the tool safely and understand the side effects, which is suitably complete for a mutation tool.

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

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

Schema has 100% coverage with descriptions for all parameters. The description adds valuable semantics by explaining the permission type mapping (1=ROLE, 2=USER, 3=CHANNEL) which the schema only conveys as integer bounds, and clarifies the bearer_token requirement as a user credential.

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

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

The description states a specific action ('Set per-command permission overrides') and identifies the exact resource (one command in a guild). It clearly differentiates from sibling permission read tools by focusing on editing rather than retrieving.

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

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

Provides context on when to use (guild-managing user with OAuth) and what it does, but does not explicitly name alternatives or contrast with read-only permission tools like commands_get_command_permissions. The auth and scope guidance is clear but no exclusionary guidance is given.

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

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

Annotations already indicate the tool is read-only, idempotent, and non-destructive, so the description does not need to repeat safety details. The description adds the return structure `{id, application_id, guild_id, permissions:[{id, type, permission}]}`, confirming it returns permission overrides for one command. While it doesn't mention potential caveats like empty overrides or authorization requirements, the annotations and simple nature of the tool make this adequate.

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

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

The description is just two sentences, with a front-loaded purpose and a separate returns section. There is no redundant or filler content; every sentence earns its place.

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

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

This is a straightforward read-only GET tool with fully described parameters and an output schema referenced in the description. The annotations and schema cover most contextual needs (safety, parameters, output), and the description adds the return shape. It could be more complete by explicitly naming the sibling tool for fetching all command permissions, but for its simplicity, it is adequately complete.

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

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

The input schema covers all three parameters with descriptions: 'Guild scope', 'Command ID (snowflake)', and 'Bot/app application ID,' achieving 100% schema description coverage. The description adds no additional parameter-level detail beyond reinforcing that the command_id is for a single command, so the baseline of 3 is appropriate.

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

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

The description clearly states 'Get permission overrides for ONE specific command in a guild,' using a specific verb and resource while explicitly scoping to a single command. The emphasis on 'ONE specific' distinguishes this tool from the sibling commands_get_guild_command_permissions, which appears to handle all commands in a guild.

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

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

The phrase 'for ONE specific command' gives clear context that this tool is intended for querying a single command's permissions rather than all commands. However, it does not explicitly name alternatives or provide when-not-to-use guidance, leaving the differentiation to the agent to infer from sibling tool names.

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

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

The description adds value beyond the read-only annotations by detailing the return shape and the nuance that `name` and `description` are raw while `untrusted_text` is a separately fenced copy. This helps the agent understand what data to expect and how to handle it. It does not cover error cases or rate limits, but the core behavioral context is present.

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

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

The description is concise and well-structured with bolded 'Purpose' and 'Returns' labels. It conveys the essential information in two short sentences with no repetitive or extraneous content.

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

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

For a simple fetch-by-ID operation, the description is fully complete: it states what the tool does, lists the return fields, and the schema covers the required parameters. Annotations cover the safety profile (read-only, idempotent, non-destructive). No critical information is missing.

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

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

Schema description coverage is 100% for both parameters (command_id and application_id), so the schema already documents their meanings. The tool description does not add any additional semantic detail about these parameters, so the baseline of 3 applies.

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

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

The description clearly states the verb ('Fetch'), the resource ('one global application command'), and the identifier ('by id'). This distinguishes it from sibling tools like commands_get_guild (which retrieves a guild command) and commands_list_global (which lists all global commands).

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

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

The description provides clear context on when to use this tool: to fetch a single global command by its ID. It does not explicitly state exclusions or alternatives (e.g., 'for guild commands use commands_get_guild'), but the scope is unambiguous and the name reinforces the distinction.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context about the return format—specifically that name and description remain raw while untrusted_text is a separately fenced copy—which goes beyond the annotation-provided safety profile.

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

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

Two short paragraphs, each earning its place: the first states purpose, the second explains returns. No fluff, well-structured and front-loaded.

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

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

Given the simple get-by-id nature, rich annotations, and full schema coverage, the description sufficiently covers the tool's operation. The return field explanation is a bonus even though an output schema exists, making the tool's behavior fully understandable.

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

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

The input schema already describes all three parameters with clear meanings (guild scope, command ID, application ID), covering 100% of parameters. The description does not add new parameter-level details beyond the schema, so it meets the baseline expected for high schema coverage.

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

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

The description clearly identifies the action ('Fetch'), the resource ('one guild-scoped command'), and the identifier ('by id'). It distinguishes from sibling tools like commands_list_guild and commands_get_global by specifying the guild scope and the target being a single command.

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

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

The description implies usage when a specific guild command needs retrieval by its ID, but it does not explicitly state when not to use it or compare with alternatives such as commands_list_guild or commands_get_global. There is no explicit exclusion or alternative guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'ALL commands' scope and the return structure, which is useful but does not go beyond what is obvious or already covered by the output schema. No additional behavioral context such as rate limits or required permissions is provided.

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

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

The description is extremely concise and well-structured with clear 'Purpose' and 'Returns' sections. Every sentence provides necessary information without any waste.

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

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

For a simple read-only list tool with two required parameters and good annotations, the description is complete. It states the purpose and return shape, and the output schema is available for detailed structure. No critical information is missing for an agent to decide 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.

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

Schema description coverage is 100% with both parameters having meaningful descriptions ('Guild scope' and 'Bot/app application ID'). The tool description does not add any further detail about the parameters, so it does not exceed the baseline provided by the schema.

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

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

The description clearly states the operation: 'List per-command permission overrides for ALL commands in a guild.' It uses a specific verb (List), identifies the resource (per-command permission overrides), and scopes it to all commands in a guild. This distinguishes it from sibling tools like commands_get_command_permissions (singular) or commands_edit_command_permissions.

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

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

The description implies usage by emphasizing 'ALL commands', but it does not explicitly state when to use this tool versus alternatives. There is no mention of when not to use it or references to other tools. The context is clear but not explicitly differentiated.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful context beyond this by detailing the return shape and warning that names/descriptions are raw app-author data with untrusted_text as a separately fenced copy. This helps set expectations about data safety.

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

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

The description is tightly structured with three labeled sections: Purpose, When to use, and Returns. Every sentence serves a clear function, and the return snippet is compact. No filler or redundancy.

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

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

With an output schema present, the return value details are covered externally. The description supplies purpose, usage context, and a summary of the response. For a simple read-only list tool with two parameters and clear annotations, this is complete.

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

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

The input schema has 100% coverage, documenting application_id and with_localizations. The description does not elaborate on parameter usage, but the schema already provides sufficient meaning, so the baseline of 3 applies.

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

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

The description opens with 'List globally-registered application commands,' using a specific verb and resource. This clearly differentiates it from sibling tools like commands_list_guild (which lists guild-scoped commands) and commands_get_global (which fetches a single global command).

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

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

The description includes a dedicated 'When to use' section: 'audit global slash commands; before bulk-overwriting global registry.' This provides clear usage context, though it does not explicitly mention when not to use the tool or name an alternative tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds the return shape and hints at its non-destructive usage, but no deep behavioral traits (e.g., pagination, rate limits) are disclosed. It does not contradict annotations.

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

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

The description is split into labeled sections (Purpose, When to use, Returns) with only 3 sentences total. Every sentence earns its place, and the most important information is front-loaded.

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

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

For a simple list tool with strong annotations, an output schema, and full parameter schema coverage, the description is complete. It covers purpose, usage context, and return format, leaving no critical gaps.

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

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

Schema description coverage is 100% with both guild_id and application_id described. The description adds no additional parameter context beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('List') and resource ('slash commands registered for a specific guild'), clearly distinguishing it from siblings like commands_list_global (global vs guild scope) and commands_get_guild (list vs single). 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.

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

Provides concrete when-to-use scenarios: 'audit which commands are registered; before bulk-overwriting.' It implies a non-global scope but does not explicitly name alternatives like commands_list_global, leaving slight room for confusion.

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

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

Annotations already indicate mutation (readOnlyHint=false) and non-destructive behavior. The description adds that it returns an updated {id, name, description, type, application_id} and that only changed fields should be sent, which is useful context beyond the annotations.

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

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

The description is extremely concise: two short sections, front-loaded with purpose, followed by return value. Every sentence adds value without unnecessary detail.

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

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

Despite the tool's complexity (15 parameters, partial updates, global scope), the description omits parameter details, prerequisites, error behavior, or when to use it over alternatives. The return value is mentioned, but overall the description is too sparse for an agent to invoke this correctly without additional schema parsing.

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

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

Schema coverage is only 13% with 15 parameters. The description mentions 'command-body fields' as a group but does not enumerate or explain specific parameters. It conveys that fields are optional for partial updates, which is helpful, but it does not compensate for the low schema coverage.

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

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

The description opens with 'Edit a global application command', which is a specific verb+resource. The word 'global' differentiates it from guild command modifiers, and the partial-update note clarifies the operation's scope.

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

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

Clearly states the tool is for global application commands and gives usage guidance ('All command-body fields are optional - pass only what changes'). However, it does not explicitly name alternative tools (e.g., commands_modify_guild) or exclusions.

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