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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it never mentions that this is a write requiring elevated permissions, that role hierarchy rules can cause failure, or what the 'confirm' flag does. With annotations present the bar is lower, but zero added context earns a 2.

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?

One short, front-loaded sentence with no filler, but this is under-specification rather than conciseness. The available budget is unused on information an agent genuinely needs for a permissioned mutation.

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 five-parameter permissioned mutation with an undocumented confirm gate, the description leaves out permissions, hierarchy constraints, idempotency behavior on repeat assignment, and parameter meaning. An output schema exists, so return values need not be explained, but the input side is entirely unaddressed.

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 0% across five parameters, and the description explains none of them. The 'confirm' boolean and 'reason' string (presumably the audit-log reason) are completely opaque, and the description does not even restate the required guildId/userId/roleId triple.

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?

States a specific verb and resource: 'Assign a role to a guild member'. This is unambiguous and separable from siblings like discord_remove_role, discord_create_role, and discord_update_role. It does not explicitly name an alternative, so it stops short of a 5.

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

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

The description gives no when-to-use context, no prerequisites (e.g. Manage Roles permission, role hierarchy position), and no pointer to discord_remove_role as the inverse operation. The agent must infer all routing from the tool name alone.

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

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

Annotations already disclose readOnlyHint=false, idempotentHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the JSON-snapshot framing but does not disclose the consequences of idempotentHint=false (repeated calls create separate snapshots), where the backup is stored, or what the snapshot covers beyond "configuration".

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?

A single front-loaded sentence with no filler; the scope (current guild configuration) and result (JSON snapshot) are stated immediately.

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?

Output schema and annotations are present and the lone parameter is fully documented, so little narrative is needed. The remaining gap is behavioral rather than structural — non-idempotency and snapshot scope/retention are never stated.

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 a single parameter at 100% schema description coverage ("Discord guild ID to snapshot", including a numeric-ID pattern), the schema does the work. The description only echoes "guild configuration" and adds no syntax or format detail beyond the schema — baseline 3.

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?

"Capture the current Discord guild configuration as a JSON backup snapshot" names a specific verb (capture) and resource (guild configuration) plus the output format (JSON). It is clearly a distinct operation from backup_list/read/diff/restore, though it never explicitly contrasts itself with those 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?

The tool's role in a backup lifecycle is strongly implied by the sibling names (list/read/diff/restore_plan/restore_apply), but the description states no explicit when-to-use, when-not-to-use, or prerequisite (e.g., should a backup be created before calling restore_plan?).

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, destructiveHint=false and closed-world scope, so the safety profile is fully covered elsewhere. The description adds some scope information by narrowing the comparison to roles and channels, but says nothing about diff direction (added vs. removed) or what happens on mismatched or missing backups. Given the annotation coverage, a 3 is appropriate.

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

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

One sentence, front-loaded with the operation and scoped to the two resources compared. No filler and no redundancy with the title.

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 only two required string params, full schema coverage, and an output schema to carry return values, the description is nearly sufficient. The only gap is operational context an agent would want — whether snapshots must come from the same guild and how unavailable IDs are handled.

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% — both beforeBackupId and afterBackupId are documented as 'Older or source' and 'Newer or target'. The description adds nothing beyond that, which is the baseline 3 case where the schema carries the parameter burden.

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 verb 'compare' plus the resources 'roles and channels' and the scope 'two stored backup snapshots' are all stated, which separates it from the create/list/read/restore siblings in the backup family. It stops short of naming an explicit alternative, but the operation is unmistakable.

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?

Usage is only implied: the tool compares two stored snapshots, so an agent can infer it belongs before a restore or audit. The description never states when to pick this instead of discord_backup_restore_plan or discord_backup_read, nor any preconditions such as both backups belonging to the same guild.

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, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so safety behavior is covered. The description adds that only snapshot IDs are returned and that they are ordered newest first, which is meaningful 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 a single sentence with no wasted words. It front-loads the operation and immediately includes the key ordering behavior.

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 zero-parameter, read-only list tool with an output schema and rich annotations, the description is largely complete. It omits pagination or empty-result behavior, but those are less critical here because the output schema and annotations carry much of the contract.

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?

There are zero input parameters and schema description coverage is 100%, so parameter semantics are inherently complete. The description correctly adds no unnecessary parameter details for a no-argument list operation.

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 and resource: it lists stored Discord backup snapshot IDs, which distinguishes it from sibling tools like backup_read that presumably retrieve details. The 'newest first' ordering adds useful specificity, though no sibling is named explicitly.

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 states what the tool does but gives no explicit guidance on when to use it versus alternatives such as discord_backup_read, discord_backup_diff, or restore tools. An agent must infer that this is the right tool when it only needs backup identifiers.

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 read-only, idempotent, non-destructive, closed-world behavior. The description adds meaningful context beyond annotations by stating that the tool validates the backup and returns sanitized metadata 'without exposing its payload,' which is a key output-safety trait.

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 a single, front-loaded sentence with no filler. Every clause contributes to purpose or behavioral context.

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 is simple (one parameter), has rich annotations, a complete schema, and an output schema, so the description needn't explain return structure or safety. It covers purpose and payload sanitization, though it leaves usage guidance unstated.

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 description does not explain the backupId parameter, but schema description coverage is 100% and the single parameter is fully documented in the schema. Baseline 3 is appropriate because the schema carries the parameter semantics.

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 ('Validate') and resource ('stored Discord backup'), and clarifies it returns sanitized metadata rather than payload. This distinguishes it from sibling backup tools like list, diff, and restore, though it does not explicitly name those alternatives.

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 does not state when to use this tool versus discord_backup_list, discord_backup_diff, or restore tools. 'Validate' implies a pre-restore context, but no explicit guidance or exclusions are provided.

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 destructive and non-idempotent, but the description adds real behavioral context beyond them: a pre-restore backup is created first, expectedPlanHash mismatches are rejected before mutation, and deletes require includeDeletes: true. It stops short of covering confirm gating or allowCrossGuild behavior, so not a 5.

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?

A single dense sentence, front-loaded with the core action and followed by safety-critical clauses in priority order. No filler sentences; each clause (pre-backup, hash gate, delete opt-in) carries distinct 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?

An output schema exists, so return values need not be explained, and the destructive-safety narrative is well covered. Gaps remain for a 7-parameter mutating tool: confirm, allowCrossGuild, and the required identity parameters are undocumented, and the source of expectedPlanHash (the plan tool) is not named.

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 0%, so the description must carry parameter meaning. It clarifies only two of seven parameters (expectedPlanHash's mismatch behavior and includeDeletes gating deletes); the required backupId/targetGuildId and the confirm, reason, and allowCrossGuild parameters get no explanation anywhere.

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?

States a specific verb and resource: 'apply role/channel create/update operations from a backup,' which distinguishes it as the execution step of the backup family. It does not explicitly name the sibling it complements (discord_backup_restore_plan) or contrast with discord_backup_diff/read, so operational differentiation is left partly to inference.

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?

Usage is implied through the expectedPlanHash gate and the pre-restore backup, suggesting a plan-then-apply workflow. However, the description never explicitly says to run discord_backup_restore_plan first or when to prefer apply over other restore-related siblings, leaving the routing to 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 state readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces non-mutation while adding that the plan compares live state and includes a stable planHash. It does not add permission, rate-limit, or scope details beyond what annotations already cover.

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?

It is a single front-loaded sentence with no waste, stating the action, safety property, comparison behavior, and a key output field.

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 rich annotations, complete parameter descriptions, and an output schema, the description is sufficient for correct invocation and clarifies the non-mutating planHash output. The only meaningful gap is the lack of explicit sibling routing guidance.

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 both required parameters are already documented. The description reinforces that backupId refers to the stored backup and targetGuildId to the live guild, but adds no format or validation detail 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 gives a specific verb and resource: create a non-mutating restore plan comparing live guild to stored backup, and includes a stable planHash. This clearly distinguishes it from the mutating restore-apply sibling, though it does not explicitly name any sibling.

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 'non-mutating restore plan' implies previewing before applying, but the description never explicitly says when to use this versus discord_backup_diff or discord_backup_restore_apply. Usage is inferable but not stated.

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 destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds real value by disclosing the confirmation gate and the backup-or-opt-out requirement that annotations do not convey. It stops short of explaining what the confirmation actually does or the consequences of banning (message deletion, reversibility via unban).

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 sentences with no filler; the action is front-loaded and the precondition follows. It is efficient, though the terseness is part of why key semantics are missing.

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?

Output schema and annotations are rich, so return values and safety need not be repeated. But this is a destructive 7-parameter mutation at 0% schema coverage, and the description leaves the backup workflow, the confirm semantics, and deleteMessageSeconds entirely unexplained — not enough for correct 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 0%, so the description must carry parameter meaning. It mentions confirm, backupId, and allowWithoutBackup by name but never explains what a backupId refers to or how to obtain one, and says nothing about guildId, userId, reason, or deleteMessageSeconds — especially the 0-604800 message-purge window, which is the most consequential 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?

States a specific verb and resource ('Ban a guild member'), which is unambiguous. However, it does not distinguish itself from closely related siblings like discord_kick_member, discord_timeout_member, discord_unban_member, or discord_bulk_ban_members, so the agent gets no help choosing among them from the description.

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 names a precondition ('Requires confirmation and either a backupId or allowWithoutBackup'), which is genuinely useful context for invocation. But it gives no guidance on when to ban versus kick/timeout, nor when the backup path should be preferred over allowWithoutBackup.

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 destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is carried structurally. The description still adds real value by disclosing the 200-user cap, the confirmation requirement, and the backup-or-opt-out gate — details not present in 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?

Two sentences, zero padding, with the capability and the gating prerequisites front-loaded in that order. Every clause carries information an agent needs.

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?

An output schema exists so return values need no explanation, and the annotations cover the destructive profile. However, for a seven-parameter destructive bulk operation, the definition omits the message-purge semantics of deleteMessageSeconds and the reason field's audit purpose, leaving notable 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 coverage is 0%, so the description must compensate, and it only explains three of seven parameters (confirm, backupId, allowWithoutBackup). It says nothing about guildId format, the userIds array bounds, the reason string, or deleteMessageSeconds — the last being a meaningfully destructive option left unexplained.

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?

States a specific verb and resource ('Ban ... users') plus the batch scope ('up to 200 users in one Discord request'), which implicitly distinguishes it from the single-user discord_ban_member sibling. It stops short of explicitly naming that sibling, so an agent must infer the distinction.

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 preconditions ('Requires confirmation and either a backupId or allowWithoutBackup') hint at when the tool is callable, but there is no explicit statement of when to choose this over discord_ban_member or discord_kick_member, and no warning about irreversibility or rate limits.

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 destructiveHint=true, non-idempotent, open-world, so the safety profile is covered. The description adds that a confirmation and backup acknowledgement are needed, which is genuine extra context, but it never explains the escape hatch (allowWithoutBackup), what happens if confirmation is omitted, or whether deletion is recoverable after a backup.

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 sentences, front-loaded with the action and mode selection, followed by the gating requirements. 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?

An output schema exists so return values need no explanation, but with 7 parameters at 0% schema coverage the description should clarify the confirm/backupId/allowWithoutBackup workflow and how to obtain a backupId. Those gaps are material for a destructive operation.

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 0%, so the description must carry the load; it loosely maps to limit, messageIds, confirm and backupId/allowWithoutBackup, but leaves 'reason' and the required channelId unexplained and does not clarify that the two deletion modes are mutually exclusive. Partial compensation only.

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?

States a specific verb and resource ('bulk delete messages') and distinguishes the two operating modes (by count or explicit message IDs), which separates it from the read-only sibling discord_list_channel_messages. It does not name a concrete alternative tool, but the action is 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?

The sentence 'Requires confirmation and backup acknowledgement' implies prerequisites but never states when to prefer count-based deletion over explicit IDs, nor when a backup must exist first. Usage conditions are implied rather than spelled out.

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, idempotentHint=false and openWorldHint=true, so the safety profile is covered externally. The description adds nothing beyond that: it does not explain what an AutoMod rule does once created, that it takes effect immediately on the guild, whether a 'confirm' flag gates the write, or any rate-limit/permission context. The unexplained 'confirm' parameter in particular is a behavioral detail only prose could supply.

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?

A single 11-word sentence with no filler, front-loaded with the action verb and resource. It wastes nothing, but the terseness is a symptom of thin content rather than a model of disciplined structure.

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?

An output schema exists, so return values needn't be described, but for an 11-parameter, deeply nested mutation tool with zero schema descriptions the one-line description is far too thin. It omits permission requirements, triggerType/eventType semantics, the confirm flag, and the relationship between triggerType and triggerMetadata — all things an agent cannot derive from an undescribed 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 description coverage is 0% across 11 parameters (5 required), including nested triggerMetadata and actions objects, and the description only gestures at 'trigger metadata and actions'. Critical fields — guildId, name, eventType, triggerType, enabled, confirm, exemptRoleIds/exemptChannelIds — get no meaning, no valid-value hints (eventType/triggerType are untyped string|number unions with no enum), and no guidance on how triggerType constrains which triggerMetadata fields are valid.

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 names a specific verb and resource ('Create a Discord AutoMod rule') and hints at the two core payload areas ('JSON trigger metadata and actions'), so an agent can tell it apart from discord_update_automod_rule / discord_delete_automod_rule / discord_list_automod_rules by the create verb. It stops short of explicitly contrasting with those siblings, so it lands at 4 rather than 5.

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

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

There is no when-to-use guidance, no prerequisites (e.g. the MANAGE_GUILD permission AutoMod requires), and no note about checking existing rules first via discord_list_automod_rules. An agent must infer everything about timing and eligibility from the name alone.

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 disclose that this is a non-read-only, non-idempotent, open-world operation. The description adds only the channel type list and does not explain the confirm parameter, permission requirements, side effects, or what happens if a channel with the same name exists.

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 a single, front-loaded sentence with no wasted words. It is appropriately sized but minimal, leaving substantial gaps that are not addressed elsewhere in the description.

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 12-parameter creation tool with no schema descriptions and no annotation-level permission detail, the description is far too thin. An output schema exists, but input-side semantics and behavioral requirements are largely 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 0% across 12 parameters, yet the description only restates the type enum values already present in the schema. It provides no meaning for guildId, name, parentId, nsfw, topic, reason, bitrate, userLimit, rateLimitPerUser, or confirm.

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 ('Create ... channel') and enumerates the supported channel types. It is clearly distinguishable from sibling mutation tools like discord_update_channel and discord_delete_channel, though it does not explicitly name alternatives.

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

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

There is no guidance on when to use this tool versus related tools, no mention of required permissions, and no explanation of prerequisites such as parentId requirements for voice/forum/stage channels. Usage is only implied by the verb 'Create'.

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 that this is a non-read-only, non-idempotent, open-world operation, so the description does not need to restate that. It adds a key behavioral detail not covered by annotations: the invite is created without returning its secret code or URL. It still omits permission requirements and the role of the confirm parameter.

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 a single front-loaded sentence with no filler, and the important caveat about not returning the secret is included. It is appropriately concise, though very terse for a 7-parameter mutation 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?

Output schema coverage reduces the need to explain return values, and annotations cover basic safety traits. However, for a 7-parameter mutation tool with no schema parameter descriptions, the description leaves major gaps around parameter meaning, confirm behavior, and usage 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 has 0% description coverage across 7 parameters, so the description must carry parameter meaning. It only implies that channelId is the target channel and does not explain maxAge, maxUses, unique, temporary, reason, or confirm.

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: create an invite for a channel. It clearly differs from sibling list/read tools, though it does not explicitly name an alternative or sibling.

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 gives no guidance on when to use this versus discord_list_invites or other invite-related operations. The usage is implied by the name and description, but prerequisites, alternatives, and exclusions are absent.

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 this is a non-readonly, open-world, non-idempotent, non-destructive mutation. The description adds no behavioral context such as permission requirements, side effects, rate limits, or what the 'confirm' parameter implies.

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 a single front-loaded sentence with no wasted words. It is appropriately sized for the amount of information it chooses to convey.

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 9-parameter mutation tool with a nested object and no parameter descriptions in the schema, the description is far too sparse. The output schema helps with return values, but the description does not provide enough context for correct 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?

With 9 parameters and 0% schema description coverage, the description only hints at the nested 'colors' object via 'primary/secondary/tertiary gradient colors.' It does not explain required fields like guildId/name or other parameters such as permissions, hoist, mentionable, reason, or confirm.

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: 'Create a Discord role.' It clearly identifies the operation, though it does not explicitly differentiate from siblings like discord_update_role or discord_delete_role beyond the verb.

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?

There is no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The only usage-adjacent detail is that gradient colors are optional.

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 this as a non-read-only, non-idempotent, open-world, non-destructive mutation. The description adds the channelId/location entity-type distinction, but it does not explain permissions, the confirm parameter, side effects, or rate limits 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 two front-loaded sentences with no filler, so it is structurally clean. However, it is arguably too terse for a 13-parameter creation tool, even if 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 complex mutation with 13 parameters, nested objects, and no schema parameter descriptions. The description covers only the channel/location split and leaves most required and optional input semantics unexplained; the output schema relieves only the return-value burden.

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 0% across 13 parameters, and the description only explains channelId and location. Required parameters such as guildId, name, scheduledStartTime, entityType, plus confirm, privacyLevel, entityMetadata, image, reason, and scheduledEndTime are left undocumented.

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 gives a specific verb and resource: 'Create a Discord scheduled event.' It is clear what the tool does and the verb distinguishes it from list/update/delete siblings, but it does not explicitly route the agent away from those alternatives.

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 gives concrete guidance for choosing between channelId and location based on event type: voice/stage vs external. That is useful selection context, though it does not state when not to use this tool or compare it directly with sibling 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=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description's one added fact, that the target channel must be text-capable, is genuinely useful context the annotations don't carry. However it says nothing about the non-idempotent consequence (repeated calls create duplicate webhooks) or the meaning of the 'confirm' flag, which is exactly the kind of behavioral detail a mutation tool should disclose.

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?

A single front-loaded sentence with no filler, and the channel-type constraint is stated up front. It is efficient, though the brevity reflects under-specification as much as discipline.

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?

An output schema exists so return values needn't be described, but for a write tool with five parameters, 0% schema coverage, and a non-idempotent mutation, the description is far too thin. An agent cannot infer when to set 'confirm', what 'avatar' accepts, or why 'reason' exists without guessing.

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 0% and the description explains none of the five parameters. Critical ones are opaque: 'avatar' (maxLength 10000000 suggests base64 image data), 'reason' (audit-log justification), and 'confirm' (apparently a confirmation safety gate) are all undocumented in both schema and description. The description only implicitly touches channelId via 'text-capable guild channel'.

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 ('Create a webhook') plus a scope constraint ('in a text-capable guild channel'), which cleanly separates it from the sibling read/delete operations (discord_list_webhooks, discord_delete_webhook). It doesn't need to name a near-identical alternative because none exists in the sibling list.

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 gives no when-to-use guidance, no prerequisites (e.g. needing Manage Webhooks permission), and no exclusions or alternative paths. The only usable cue is the 'text-capable channel' restriction, which is a constraint rather than 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?

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds no behavioral context such as irreversibility, permission requirements, or what happens to the rule's configuration.

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?

It is a single, front-loaded sentence with no wasted words. However, it is under-specified rather than appropriately sized for a destructive tool with six parameters.

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 output schema and annotations cover return values and safety hints, but the description omits critical context for a destructive operation: required permissions, the role of confirm/backupId, and consequences of deletion.

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 6 parameters with 0% description coverage, including non-obvious optional parameters like confirm, backupId, and allowWithoutBackup. The description provides no parameter meaning at all.

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: deleting a Discord AutoMod rule. The purpose is clear, but it does not distinguish this tool from siblings like discord_update_automod_rule or discord_create_automod_rule beyond the verb itself.

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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The only implied usage is the literal act of deletion.

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 destructiveHint=true, idempotentHint=false and openWorldHint=true, so the danger profile is covered structurally. The description adds real value by disclosing the confirmation and backup-acknowledgement gate, but omits what the deletion destroys (messages, threads), what allowWithoutBackup does, and whether permissions are required.

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?

A single front-loaded sentence with no filler, and the safety precondition is placed before any other detail. It is efficient, though the terseness comes partly at the cost of information the agent needs.

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 destructive, irreversible mutation with five undocumented parameters. The output schema removes the need to describe return values, but the description still leaves the confirm/backupId/allowWithoutBackup interaction and the destruction scope unexplained, which is a serious gap for a delete 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 0% across five parameters, so the description carries the full burden. It only hints at 'confirm' and 'backup acknowledgement' (backupId / allowWithoutBackup) and says nothing about channelId format or the purpose of the optional 'reason' audit field.

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?

Names a specific verb and resource ('Delete a Discord guild channel'), which clearly separates it from sibling mutations like discord_delete_role or discord_update_channel. However, it doesn't explicitly contrast with alternatives or state the scope of the deletion (messages, threads, 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 phrase 'after confirmation and backup acknowledgement' implies prerequisites but never states when to use this tool versus discord_backup_create / discord_backup_restore_plan or discord_update_channel. The agent must infer the workflow rather than being routed to 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotency, so the safety profile is covered structurally. The description adds the important behavioral precondition of confirmation and backup acknowledgement, but it does not explain irreversibility, permission requirements, or what deletion does to members holding the role.

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?

A single front-loaded sentence that identifies the action and its preconditions without filler. Every phrase contributes to the operation.

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 destructive, six-parameter operation with no schema descriptions, so the description should do more. It omits required parameter meaning, the irreversible consequences of role deletion, and how confirmation/backup acknowledgement are supplied, leaving major gaps for an agent.

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 0% for six parameters, so the description must compensate and largely fails to do so. It vaguely gestures at 'confirmation' and 'backup acknowledgement' but gives no meaning for guildId, roleId, reason, confirm, backupId, or allowWithoutBackup.

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?

States a specific verb and resource ('Delete a Discord role'), which clearly separates it from siblings like discord_update_role or discord_remove_role. The added precondition phrase does not obscure the core action.

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 'after confirmation and backup acknowledgement' implies prerequisites for use, which is useful context. However, it does not state when to choose deletion over alternatives such as updating or reassigning a role, nor what happens if the preconditions are not met.

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 destructiveHint=true and idempotentHint=false, so the safety profile is covered. Yet the description adds nothing: it does not say the deletion is permanent, whether a reason is audited, or why confirm, backupId, and allowWithoutBackup exist. Those schema fields strongly imply a confirmation/backup gate that is left entirely undisclosed.

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 single sentence is front-loaded and wastes no words, but it is under-specified rather than appropriately concise for a destructive tool with six parameters. Brevity here comes at the cost of the information the agent needs.

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?

An output schema exists, so return values needn't be described, and annotations cover destructiveness. But for a destructive, non-idempotent operation with an undocumented confirmation/backup workflow, the definition omits behavior an agent must know to invoke it safely.

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 0% across 6 parameters, and the description explains none of them. Critical fields such as confirm, backupId, and allowWithoutBackup carry non-obvious semantics that neither schema nor description clarify, so the description fully fails to compensate for the coverage gap.

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 names a specific verb and resource (delete a scheduled event), so the operation itself is unmistakable. However, it is essentially the tool name and title restated as a sentence and adds no scope detail such as whether the event is cancelled/notified or what a deletion affects. An agent learns nothing beyond what the identifier already told it.

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?

There is no statement of when to use this tool, no mention of the sibling tools (discord_list_scheduled_events, discord_create_scheduled_event, discord_update_scheduled_event), and no guidance on prerequisites. Given the presence of confirm/backup parameters in the schema, the absence of any guidance on the required workflow is a real gap.

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 destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds meaningful context beyond annotations: that confirmation is required and that deletion must be preceded by a backupId or an explicit allowWithoutBackup opt-in, which is genuinely useful for a destructive operation.

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 sentences, front-loaded with the action and followed by the critical requirement, with zero wasted text.

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?

An output schema exists so return values need not be explained, and annotations cover the safety profile. The description is nearly complete for a destructive delete tool, with the minor exception of the undocumented 'reason' parameter.

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 0%, so the description must compensate. It conveys meaning for webhookId, confirm, backupId and allowWithoutBackup, but leaves the 'reason' parameter entirely undocumented and gives no format details (e.g. the webhookId numeric pattern), so it only partially fills the gap.

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 gives a specific verb and resource ('Delete a webhook by ID') that clearly distinguishes it from siblings like discord_create_webhook and discord_list_webhooks. It stops short of explicitly naming those alternatives, but the purpose is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives such as the backup/restore tools, nor any exclusions. The 'requires confirmation and either a backupId or allowWithoutBackup' line sets operational prerequisites rather than 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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=true, so the safety profile is fully covered. The description adds nothing beyond that—no note about live API calls to Discord, permission requirements to view the channel, or behavior when the channel is missing or inaccessible.

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 single sentence is front-loaded and free of padding, which is good, but its brevity comes at the cost of any substantive information—it is under-specification framed as conciseness.

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?

An output schema exists, so return values need not be explained, but for a tool with two required, undescribed ID parameters and no usage guidance, the description leaves the agent without enough to invoke it confidently or recover from a wrong-ID error.

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 0%, so both required parameters (guildId, channelId) are documented only by regex patterns. The description does not explain that these are Discord snowflake IDs, nor clarify the parent guild vs. target channel relationship, so it fails to compensate for the coverage gap.

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?

States a specific verb+resource: fetching metadata for a single Discord channel, which distinguishes it from the many list_* siblings. However, it never explicitly contrasts with discord_list_channels or discord_get_guild, so the agent must infer the singular-vs-list distinction.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as discord_list_channels when the channel ID is unknown. The agent is left to infer that this tool requires a known channelId and is not a discovery mechanism.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond 'metadata' — nothing about freshness, permission requirements, or what happens if the guild is inaccessible.

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 a single front-loaded sentence with no filler. Its brevity is clean, though it borders on under-specification rather than optimal conciseness.

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 is simple and has an output schema, so return values need not be explained. However, the description leaves the sole required parameter entirely unexplained and does not differentiate this tool from discord_list_guilds, leaving important context gaps for an agent.

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?

There is one required parameter, guildId, and schema description coverage is 0%. The description says 'guild' but never mentions the ID parameter, its required status, or its 17–20 digit numeric format, so it fails to compensate for the undocumented 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 uses a specific verb and resource ('Get Discord guild') and adds a scope hint ('metadata'), so an agent can tell it retrieves a single guild record. It does not explicitly distinguish this from the sibling discord_list_guilds tool, which keeps it below a 5.

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?

There is no guidance on when to use this tool instead of discord_list_guilds or other guild-adjacent tools. The only implied usage is retrieving metadata for a guild whose ID is already known, but that is not stated.

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, non-destructive, and openWorldHint, so the safety profile is fully covered. The description adds nothing beyond that: no note on required bot permissions, intents, error behavior for missing roles, or scope of 'metadata'.

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?

One short, front-loaded sentence with zero waste, but it is under-specified rather than concise-in-a-good-way; there is no structure beyond the single clause.

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?

An output schema exists, so return values need not be described. However, for a two-required-parameter tool with 0% schema description coverage, the absence of any parameter or scope context leaves an agent guessing.

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 0%, so the description carries the burden for guildId and roleId, yet it never mentions them. It gives no hint that roleId is scoped to a guild, or that both are 17-20 digit snowflakes (the pattern exists in the schema but is unexplained).

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 ('Get Discord role metadata'), making the single-role fetch reasonably clear against siblings like discord_list_roles. It stops short of explicitly contrasting itself with the list/create/update/delete role tools, but the read-one semantics come through.

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?

There is no guidance on when to use this instead of discord_list_roles, discord_get_guild, or discord_update_role. The agent must infer the selection rule from the name alone.

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 flag the operation as destructive, non-idempotent, and open-world. The description adds useful behavioral context by stating that confirmation is required and that a backup or explicit no-backup allowance is needed, which materially affects how an agent should invoke 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?

Two short sentences, front-loaded with the action and then the mandatory conditions. No wasted wording.

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 moderation tool, the description gives essential gating conditions but omits permission requirements, expected effect details, and how kick compares with sibling moderation actions. The output schema exists, so return values need not be described.

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 0%, so the description must compensate. It explains the conditional relationship around confirm, backupId, and allowWithoutBackup, but leaves reason and the exact semantics of backupId and guildId/userId unaddressed beyond their names.

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?

States a specific verb and resource: "Kick a guild member." This is clear, though it does not explicitly distinguish the action from sibling tools such as ban_member or timeout_member.

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 key prerequisite: confirmation and either backupId or allowWithoutBackup. However, it does not explain when to choose kick over ban, timeout, or other moderation actions, nor when a backup is appropriate versus bypassing 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context such as authentication needs, pagination, or what is returned. For a simple list tool this is a minor gap, but it provides essentially no transparency 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 a single, front-loaded sentence with no wasted words. It is extremely concise, though arguably under-specified rather than optimally sized for a tool with an undocumented parameter.

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?

An output schema exists, so return values do not need explanation, and annotations cover the safety profile. However, the description leaves the only parameter completely unexplained and gives no usage context, which is a noticeable gap for a tool whose schema has 0% description coverage.

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 0%, and the only parameter (guildId) is undocumented in the description. The description implies a guild context through the phrase 'guild application commands,' but it does not explain that guildId is required, its format, or its role. The schema provides a pattern, but the description does not compensate for the coverage gap.

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 ('List') and resource ('guild application commands'), so the basic purpose is clear. However, it nearly restates the title and name, adding almost no scope or differentiation beyond that. It does not clarify what an application command is or how this listing differs from other list tools beyond the resource name.

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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent is left to infer that this is for retrieving commands for a guild without any context about when that would be 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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered; the description adds the non-obvious bot permission requirement, which is real value. However, it says nothing about ordering (newest-first?), pagination via the after/before cursors, the 50 default / 100 max limit, or rate-limit behavior of the audit log endpoint.

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 sentences with zero waste and the core action front-loaded ahead of the permission caveat. Nothing could be removed without losing 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?

An output schema exists, so return values need not be explained, but for a six-parameter filtered list tool with no schema descriptions the description is far too thin: filtering semantics, cursor pagination, and result ordering are all 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 0% across six parameters, so the description carries the full burden and supplies almost nothing. It never mentions guildId, the userId and actionType filters, or that after/before are snowflake cursors — an agent must infer all of that from bare property names and regex patterns.

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?

States a specific verb and resource ('Read ... Discord audit log entries') and no sibling covers audit logs, so the tool is clearly distinguishable. 'Recent' hints at recency ordering but is left unqualified.

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 only guidance is a prerequisite ('Requires the View Audit Log permission for the bot'), which is useful but is not when-to-use guidance. There is no statement of when an agent should reach for this versus, say, listing bans or automod rules, nor any note about how to narrow the query.

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/non-destructive and openWorld, so safety is covered. The description adds the guild scoping but nothing about permissions required, pagination, or coverage of rule types – a modest but not negligible addition.

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?

A single short sentence, front-loaded and waste-free. It is arguably too terse rather than too long, so it scores well on structure but not perfectly on usefulness density.

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?

An output schema exists, so return values needn't be explained, and annotations cover the safety profile. However, for a one-param tool with 0% schema coverage, the description should at least identify the required guildId and any permission prerequisite, which it omits.

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 0%: the single guildId parameter has no description, no format hint in the schema beyond a regex pattern, and the description does not mention it at all. With only one parameter the bar is low, but nothing is added here to explain what guildId must be.

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?

Specific verb (List) plus resource (AutoMod rules) scoped to a Discord guild. It distinguishes itself from the mutation siblings discord_create_automod_rule/update/delete by name, though it doesn't explicitly say so.

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?

Usage is implied by the read-only 'List' framing and the automod family of siblings, but the description never states when to use this versus the create/update/delete variants or what prerequisites (e.g. MANAGE_GUILD permission) are needed.

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, so safety is covered. The description adds two useful behavioral details beyond that: the permission requirement and the fact that results are paginated. It stops short of describing pagination semantics, rate limits, or error behavior, which keeps it at an adequate rather than rich level.

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 compact sentences with no wasted words. The core action is front-loaded and the prerequisite follows immediately.

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?

An output schema exists, so return values need not be explained. The description covers purpose, permission, and the existence of pagination, but with 0% schema description coverage it leaves the cursor parameters under-specified. For a paginated list tool this is workable but not fully 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?

Schema description coverage is 0%, so the description must compensate for four undocumented parameters. It only says 'with pagination', which hints that before/after/limit are cursor-related but does not explain that they are snowflake IDs, how the cursors interact, or what the limit bounds mean. guildId is implied by 'guild bans' but not explained either.

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?

States a specific verb and resource ('List guild bans') that is unambiguously distinct from mutation siblings like discord_ban_member and discord_unban_member. It does not explicitly name an alternative, but the intent is clear without opening the schema.

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 supplies a concrete prerequisite ('Requires the Ban Members permission'), which is useful usage context. However, it gives no guidance on when to choose this tool over related ones such as discord_get_guild or member search, and no exclusions or failure conditions are described.

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, openWorldHint, and destructiveHint=false. The description adds meaningful behavioral context by requiring ENABLE_MESSAGE_CONTENT=true and the Discord Message Content privileged intent, which is a critical operational prerequisite not covered by 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?

Two short sentences with no filler; the core operation and critical prerequisite are 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?

An output schema exists, so return values need not be described. However, with six parameters at 0% schema description coverage, the description is incomplete because it omits pagination, filtering, and required-ID semantics that an agent needs to 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 0%, and the description does not explain any of the six parameters. In particular, it says nothing about guildId, channelId, limit, after, before, or around, leaving pagination and filtering semantics entirely undocumented.

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: 'List recent messages from a text-based channel.' It clearly distinguishes a message-listing operation from channel-management siblings, but does not explicitly differentiate from any near-alternative message tool.

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 no when-to-use or when-not-to-use guidance, nor does it name alternatives. It only states a prerequisite, which is useful but not 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond restating that it lists channels—no mention of rate limits, pagination, or authentication requirements—so it contributes little beyond the structured fields.

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 a single, front-loaded sentence with zero wasted words. It gets straight to the point and is appropriately sized for a simple list operation.

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

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 and comprehensive annotations, the description covers the basic purpose adequately. However, it omits parameter semantics (guild ID format) and behavioral details like pagination, leaving some gaps for an agent to infer.

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 0%, so the description must compensate by explaining the sole parameter guildId. It only says 'in a Discord guild,' which vaguely implies a guild identifier but gives no details on format, source, or required pattern, adding minimal meaning 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 a specific verb ('List') and resource ('channels') within a clear scope ('in a Discord guild'). This distinguishes it from siblings like discord_get_channel (single channel) and discord_list_guilds (guilds), so an agent can immediately understand 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 offers no guidance on when to use this tool versus alternatives such as discord_get_channel for detailed channel info. It also omits prerequisites (e.g., required permissions) and any conditions or exclusions, leaving usage entirely implicit.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is fully covered. The description adds nothing beyond that: no mention of whether it returns only custom guild emojis versus global ones, pagination, or permission/rate-limit behavior. With annotations carrying the burden, this is adequate but adds no extra 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?

A single sentence with no filler, and the key scope ('in a Discord guild') is front-loaded. It is efficient, though the terseness borders on under-specification rather than tightness.

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, read-only list operation with full annotations and an output schema, the description covers the minimum needed to call it. It omits useful context such as the scope of emojis returned and pagination behavior, which is a clear but modest 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?

Schema description coverage is 0%, so the description must compensate for the single guildId parameter. 'in a Discord guild' only weakly ties guildId to the guild identifier and gives no format or sourcing guidance, leaving the agent to infer meaning from the parameter name and the regex pattern alone.

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 ('List') and resource ('emojis') scoped to a Discord guild, so an agent knows exactly what the tool returns. It does not differentiate itself from near neighbors like discord_list_stickers, but the resource noun is distinct enough to select on.

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?

There is no statement of when to use this tool versus alternatives (e.g., discord_get_guild or discord_list_stickers), and no prerequisites such as requiring the guild ID or emoji-related permissions. Usage is only implied by the name and the word 'List'.

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, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description contributes one genuinely useful behavioral fact — results are bounded by what the bot can actually see — but says nothing about pagination or result size.

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?

A single front-loaded sentence with no filler. Every clause earns its place by adding the visibility constraint rather than restating the name.

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 no inputs, an output schema present, and rich annotations, the description only needs to convey scope — which it does. A brief note on ordering or expected result volume would close the last 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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The scope phrase does clarify the implicit filter (bot membership) that acts in place of a 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?

States a specific verb+resource ('List Discord guilds') and adds a scope qualifier ('visible to the configured bot') that separates it from discord_get_guild. It doesn't explicitly name the sibling, but the plural-vs-singular distinction is self-evident from the names.

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?

No explicit when-to-use guidance or named alternatives; usage is only implied by the 'list' verb and the bot-visibility scope. An agent can infer this is the enumeration entry point that precedes discord_get_guild / discord_list_channels, but it has to infer 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?

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description still earns credit by disclosing a non-obvious behavioral constraint that annotations cannot express: invite codes and URLs are deliberately omitted, which prevents an agent from expecting usable invite links.

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?

One compact sentence with the operation front-loaded and the most surprising caveat (codes/URLs omitted) placed where it will be read. Nothing redundant.

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 rich annotations, the description needn't explain return values. It correctly sets expectations about redacted fields; only pagination/limit behavior for large guilds is unaddressed, a minor gap for a single-parameter list 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 0% for the single guildId parameter, though its snowflake pattern is machine-visible. The description only hints at guild scoping ('in a Discord guild') and adds no format or validation guidance beyond the schema, so it does not fully compensate for the coverage gap.

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?

States a specific verb (List) and resource (invite metadata) plus its scope (in a Discord guild). It clearly contrasts with the write-side sibling discord_create_invite by being a read lister, though it never names an alternative explicitly.

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?

Use is implied by the 'non-secret invite metadata' framing, but there is no explicit when-to-use or when-not-to-use statement, and no pointer to alternatives such as discord_create_invite or audit-log tooling. An agent must infer the 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 declare readOnly, idempotent, openWorld, non-destructive, so the safety profile is covered. The description adds a genuine behavioral fact — the total result set is capped at 1000, not just per-page — which goes slightly beyond the schema's per-request maximum. It says nothing about pagination mechanics via the cursor or whether results are truncated silently.

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?

One short, front-loaded sentence with zero filler. It is terse to the point of under-specification for a three-parameter paginated tool, but nothing in it is wasted.

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?

An output schema is present, so return values needn't be explained, but with 0% parameter coverage the description leaves the pagination contract (after/limit) undocumented and gives no hint that member listing may be incomplete in large guilds. For a list tool with a cursor, this is not sufficient 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 0%, so the description must compensate and it largely does not: guildId is only implied, limit is only alluded to via 'capped at 1000', and the 'after' cursor parameter is never mentioned at all. An agent reading only the description would not know pagination exists.

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?

States a specific verb and resource ('List guild members') plus a global result cap, so the operation is immediately identifiable. It does not distinguish itself from the sibling discord_search_members, which is the obvious alternative for the same resource.

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?

There is no when-to-use guidance, no mention of prerequisites (e.g. intents/permissions needed to enumerate members), and no reference to discord_search_members as the alternative for filtered lookups. The agent must guess whether this is the right tool for finding a specific member.

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 establish that this is a safe, read-only, idempotent operation, so the description has a lower burden. It adds only that the counts reflect members currently holding each role, without detailing permissions, limitations, or freshness beyond that.

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 a single front-loaded sentence with no wasted text. It communicates the core operation 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?

For a simple read-only tool with one parameter and an output schema, the definition is minimally sufficient: it says what is returned. However, it does not compensate for the undocumented guildId parameter or provide sibling-tool routing, leaving clear 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 0%, so the description should compensate for the undocumented guildId parameter, but it does not explain that guildId is a Discord guild snowflake ID. The word 'guild' appears, but the parameter's meaning and required format are left entirely to 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 a specific verb and resource: listing role member counts, not roles themselves. It is clear enough to distinguish this from sibling tools like discord_list_roles and discord_list_members, though it does not name those alternatives explicitly.

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 no explicit when-to-use guidance, prerequisites, or alternatives. An agent can infer that it is for retrieving per-role member counts, but there is no help choosing it over discord_list_roles or discord_list_members.

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, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds nothing beyond that — no note on pagination, ordering, permission requirements, or the open-world/network nature of the call.

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?

A single front-loaded sentence with zero waste. However, the brevity tips into under-specification rather than optimal conciseness.

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?

An output schema exists, so return values need not be explained, and annotations cover safety. But the lone required parameter's meaning is undocumented anywhere, leaving a real gap for an agent trying 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?

The single guildId parameter has 0% schema description coverage — only a regex pattern is given. The description does not explain that guildId is the target guild's snowflake ID or how to obtain it, so it fails to compensate for the schema gap.

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?

States a clear verb ('List') and resource ('roles in a Discord guild'), so an agent knows exactly what it returns. It does not explicitly contrast with siblings like discord_get_role or discord_list_role_member_counts, keeping it below a 5.

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?

There is no guidance on when to use this versus discord_get_role, discord_list_role_member_counts, or the role-mutation tools. The agent must infer the context from the name alone.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered elsewhere. The description adds essentially nothing beyond that - no pagination behavior, no ordering, no note on which event states are returned - making it a restatement of the title.

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?

A single front-loaded sentence with zero filler. It is efficient, though the brevity leaves specification gaps rather than being optimally informative.

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?

An output schema exists, so return values need not be described. However, for a listing tool the agent still lacks any hint about result size, pagination, or filtering, and the single required parameter is undocumented in both schema and description.

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 0%, but there is only one parameter (guildId) and the phrase 'in a Discord guild' implies it scopes the query to that guild. No format or source detail (e.g. snowflake ID) is added, so it only marginally compensates for the coverage gap.

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?

States a specific verb (List) and resource (scheduled events) with scope narrowed to a Discord guild. It is clearly distinguishable from the write siblings discord_create_scheduled_event / update / delete, though it does not name them explicitly.

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?

There is no when-to-use guidance, no mention of alternatives, prerequisites (bot permissions like VIEW_GUILD_SCHEDULED_EVENTS / GUILD_SCHEDULED_EVENTS intent), or whether it covers past vs upcoming events. Usage is only inferable from the verb 'List'.

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 the safety profile is fully covered. The description adds nothing beyond the guild scoping already implied by the tool name — no pagination behavior, no statement of whether only guild-specific stickers (not built-in ones) are returned.

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?

A single short sentence with no padding, front-loaded on the verb. It is arguably under-specified rather than verbose, but as raw conciseness it is efficient.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a list operation the description omits pagination/limit behavior and the scope of stickers returned, leaving a real gap before an agent can call it confidently.

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?

There is one parameter, guildId, with 0% schema description coverage — only a regex pattern constrains it. The description's phrase 'in a Discord guild' only weakly signals that guildId is required and does not explain the 17-20 digit snowflake format or where to obtain 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?

States a specific verb ('List') and resource ('stickers') scoped to a Discord guild, so the operation is unambiguous. It doesn't distinguish itself from sibling list tools like discord_list_emojis, which is the nearest same-kind resource, but the resource name alone is fairly distinctive.

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?

No guidance on when to use this versus alternatives such as discord_list_emojis, nor any stated prerequisites (e.g., needing a guild ID resolved via discord_list_guilds). The agent must infer usage entirely from the name.

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, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely new context the annotations do not: returned webhook objects are token-sanitized, which is important for an agent deciding whether this is safe to surface in output.

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?

One sentence, front-loaded with the operation and scope, with the security qualifier trailing. No redundant phrasing and nothing to trim.

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 rich annotations, an output schema, and one well-typed parameter, the description covers what an agent needs to select and call this tool. The only minor gap is silence on pagination/result limits for a potentially large webhook list.

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 0%, but with a single required parameter whose type and 17-20 digit snowflake pattern are already encoded in the schema, the burden is light. The description does not restate or clarify guildId, but the schema is self-explanatory enough that a 3 is reasonable.

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?

States a specific verb+resource ('List webhooks') scoped precisely to 'a Discord guild', and adds the notable output constraint 'without exposing tokens'. An agent can distinguish it instantly from discord_create_webhook and discord_delete_webhook without opening a schema.

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?

Usage is implied by the verb and the webhook siblings (create/delete) make the read variant obvious, but there is no explicit when-to-use guidance, no prerequisites, and no named alternatives. Minimum viable.

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 destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds only a minimal scope clarification that the role is removed from a member rather than deleted globally; it says nothing about permissions, the confirm parameter, audit-log reason behavior, or what happens if the member lacks the role.

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 single sentence is front-loaded and free of waste, but it is under-specified rather than appropriately concise for a destructive five-parameter tool. The structure is clean but too thin to earn a higher score.

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 with five parameters, 0% schema coverage, and no annotation about permissions or confirmation, the description is substantially incomplete. The output schema reduces the need to describe return values, but the input-side and safety context remain largely absent.

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 0%, and the description names none of the five parameters. It implies that a member and a role are involved, but guildId, reason, and confirm are completely unexplained, and even the implied parameters lack naming or format detail.

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: remove a role from a guild member. This distinguishes it implicitly from discord_delete_role, which removes the role itself, but it does not explicitly name or contrast with sibling tools such as discord_assign_role.

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?

There is no guidance on when to use this tool versus discord_assign_role, discord_delete_role, or discord_update_role. The usage context is only implied by the verb 'Remove' and the phrase 'from a guild member.'

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 disclose destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is partly covered. However, the description says nothing about what 'destructive' means here (whether unlisted channels are displaced), what the 'confirm' parameter guards, whether the 'reason' is written to the audit log, or how partial position lists are handled.

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 single sentence is front-loaded and free of padding, but it is under-specified rather than concisely complete. It earns its brevity at the cost of omitting operational details an agent needs.

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 destructive, batch-oriented mutation with a confirm gate and an audit-log reason, and the output schema covers return values. The description omits the confirmation requirement, the semantics of the positions array, and the destructive consequences, leaving significant gaps for a tool of this 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 description coverage is 0%, so the description must carry the burden for guildId, positions, reason, and confirm. It only vaguely implies guildId and positions via 'within a guild' and 'channel positions'; it says nothing about the positions array structure, the 0-499 range, the confirm gate, or the audit-log reason string.

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 ('Set'), resource ('channel positions'), and scope ('within a guild'), so an agent can tell it is a bulk reorder operation rather than a single-channel update. It does not explicitly differentiate itself from siblings like discord_update_channel or discord_reorder_roles, but the name plus description are 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?

There is no guidance on when to use this tool versus discord_update_channel or discord_reorder_roles, nor any mention of prerequisites such as needing manage-channels permission. The agent must infer usage entirely from the name.

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