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

The description only restates the basic action and adds no behavioral context beyond what annotations already convey. It does not mention idempotency, failure behavior, permissions, or side effects despite being a mutating open-world 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?

The description is one short, direct sentence with no wasted words. It front-loads the core operation 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?

For a three-parameter mutation with no parameter descriptions, this is thin. An agent gets no guidance on how to supply channel_id and message_ts correctly or what valid reaction values look like; the output schema helps only on the return side.

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 needed to compensate, but it only hints at the 'reaction' parameter. The meanings and formats of channel_id and message_ts are left entirely to inference from 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?

The description names a specific verb ('add') and a clear resource ('a reaction to a message'), which distinguishes it from message-posting tools like post_message. It does not explicitly differentiate itself from get_reactions, so it loses the top score.

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 intended use is implied: use this when you need to attach a reaction to a message. However, it provides no explicit guidance about when not to use it or how it relates to alternatives like get_reactions.

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

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

The description discloses the non-obvious workaround: the usergroup is set to contain only a randomly selected deleted user. This is meaningful behavioral context beyond the destructiveHint and readOnlyHint annotations, and it also documents the return behavior.

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

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

The description is compact and well-structured: a clear one-line purpose, a brief workaround explanation, then Args and Returns sections. Every sentence earns its place with no filler.

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

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

For a simple one-parameter mutation tool, the description covers purpose, the reason for the workaround, the parameter semantics, and return values. Combined with the annotations, an agent has enough information to invoke and interpret the tool correctly.

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

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

The input schema provides no description, but the Args section fully explains the single parameter: 'the usergroup ID (S...) to clear.' This adds semantic meaning and a format hint that the schema lacks.

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

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

The description opens with a specific verb and resource: 'Clear all users from a Slack usergroup.' This clearly distinguishes the tool from siblings like update_usergroup_members, which manage membership rather than clear it entirely.

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 explains the context and rationale for the tool: Slack API doesn't support empty usergroups, so this tool uses a workaround. This makes the intended use clear, though it does not explicitly name alternatives or state when not to use the tool.

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

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

Annotations already indicate a non-read-only, state-changing tool. The description adds useful behavioral detail beyond annotations, including name sanitization, the default for is_private, and the return contract of Channel ID or None. This is valuable context for predicting tool behavior.

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

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

The description is compact and front-loaded with the core purpose, followed by a structured Args/Returns breakdown. Every sentence provides necessary information with no filler.

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

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

For a low-complexity tool with two parameters and an output schema present, the description covers the essential operational details: channel creation, parameter semantics, defaults, and failure return. Nothing critical is missing 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?

The input schema has 0% description coverage, but the description fully compensates by explaining both parameters: name's sanitization rules and is_private's default and meaning. This is exactly the semantic information an agent needs beyond raw types.

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

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

The description states 'Create a new Slack channel' with a specific verb and resource, clearly distinguishing it from siblings like join_channel and rename_channel. The purpose is immediately obvious and unambiguous.

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

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

The description clearly indicates this tool is for creating new channels, which is a distinct use case from joining, renaming, or messaging. It does not explicitly name alternatives or exclusion conditions, but the usage context is clear enough for an agent to route correctly.

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

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

Beyond the readOnly/openWorld hints, the description discloses pagination support, default limits, acceptable date formats, thread-inclusion behavior, and boundary semantics for date-only values. This is materially richer than the annotations alone.

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 summary line is front-loaded, and the optional parameters are organized as a scannable list with examples. Every sentence adds value; the date-boundary note closes the one genuinely non-obvious 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?

The description covers all parameters, defaults, and date parsing in detail, and an output schema exists to explain return values. It leaves a small gap around how pagination actually works and how include_threads interacts with limit/date filters, but nothing blocks a competent agent from making a correct call.

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

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

With 0% schema description coverage, the description carries full responsibility for documenting parameters, and it does so thoroughly: limit's meaning and default, oldest/latest formats with examples, and include_threads behavior. Only channel_id is left to the schema, where its name is self-explanatory.

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 opening sentence states the exact operation and resource: retrieving a channel's message history. It adds pagination and thread behavior, distinguishing it from thread-specific or search-based sibling tools even though it doesn't name them.

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

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

The description provides clear context: it is for fetching a channel's full history, with optional date filters and thread inclusion. It does not explicitly exclude search_channel_messages or get_thread, so it misses the 'when not to use' guidance that would earn a 5.

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

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

Annotations already mark this as read-only and open-world, so the safety profile is covered. The description adds a useful behavioral detail about accepting the optional '#' prefix, but it does not disclose behavior for missing channels, case sensitivity, or which set of channels is searched.

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 primary action is stated first, and the key formatting exception is given immediately after. Every word 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?

The tool is simple and an output schema exists, so return values do not need to be described. However, the description omits useful scope information (e.g., whether the lookup covers all channels or only channels the bot has joined) and does not address not-found behavior, which matters for deciding whether to call join_channel first.

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 0% schema description coverage, the description must carry the parameter meaning. It does add the important rule that the channel name may be with or without the '#' prefix, which is not present in the schema. It leaves some ambiguity about exact formatting, but for a single required string parameter this is meaningful guidance.

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 ('get') and resource ('channel ID') and identifies the exact input ('channel name'). It is clearly distinct from sibling tools like get_channel_history or resolve_user_id, which operate on different resources or return different data.

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

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

The description implies the tool should be used whenever a channel ID is needed from a channel name, but it does not explicitly contrast it with alternatives or state prerequisites such as whether the channel must be joined. No exclusions or 'use X instead' guidance is 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 provide readOnlyHint=true, so the safety profile is covered. The description adds no extra behavior such as whether 'full' affects the payload, pagination, or ordering; with annotations present a neutral 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?

A single short sentence that immediately communicates the operation with no filler. It could slightly improve by front-loading parameter-relevant behavior, but for its size 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?

The tool is simple and has an output schema plus read-only annotations, so the minimal description is mostly adequate. However, the unlabeled 'full' parameter and lack of any usage/routing context leave a clear completeness gap for an agent invoking 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 needed to compensate, but it explains none of the three parameters. channel_id and message_ts are inferable from names, but 'full' (boolean, default true) has no explanation and is genuinely ambiguous.

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 clear verb and resource ('Get reactions to a message') and is not a tautology. It is readily distinguishable from sibling add_reaction as the read counterpart, though it does not explicitly contrast with 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?

No guidance is given for when to prefer this tool over add_reaction or other reaction-related operations. The intended context is implied by the name, but there are no explicit conditions, exclusions, or alternatives.

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

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

Annotations already mark this as readOnlyHint=true, so the description does not need to restate safety. It adds context by clarifying that thread_ts is the parent message timestamp, but does not disclose ordering, pagination effects of limit, or behavior when no thread 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?

Three concise sentences, each earning its place: the action, the recommended use case, and key parameter clarification. The most important identifying phrase is front-loaded.

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

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

For a simple read-only fetch with an output schema available, this is largely complete. It gives the purpose, usage context, and defines the critical parameter. The only notable omission is how limit affects returned messages, but this is optional and defaults to 100.

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 does explain thread_ts as 'the timestamp of the parent message' and mentions channel ID as an input. However, it ignores the optional limit parameter entirely, leaving its meaning to the schema's default.

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

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

Description opens with a specific verb-resource pair: 'Get all messages in a thread' and names the two required inputs. This clearly differentiates it from sibling get_channel_history by focusing on thread context rather than channel history.

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?

Explicitly guides usage: 'Use this to read a full conversation thread before replying to it.' This gives clear context but stops short of listing alternatives or when-not-to-use conditions like get_channel_history would be preferred.

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

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

Annotations already indicate mutation and potential destructive effects, so no credit is given for that. The description adds the return contract — 'True if all invitations succeeded, False otherwise' — which is useful, but it does not disclose partial-failure behavior, duplicate handling, or permission requirements.

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

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

The description is compact and well-structured with a one-sentence purpose, Args block, and Returns block. There is no filler; every sentence adds information needed to invoke the 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?

For a two-parameter tool, the description is largely complete: it explains both inputs, their format, and the boolean result. The main gap is absence of usage context and edge-case behavior, but given the low complexity and supportive annotations, the remaining gaps are minor.

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

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

Although schema coverage is 0%, the description compensates by defining both parameters with meaningful hints: channel_id is a target C... channel ID and user_ids is a list of U... user IDs. This provides format and role information not present in the schema's bare type declarations.

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

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

The description opens with a specific verb and resource: 'Invite multiple users to a channel.' It clearly identifies the action, the target, and the object. This differentiates it from sibling tools like join_channel, create_channel, and send_dm without needing 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?

No guidance is given about when to choose this over alternatives such as join_channel, create_channel, or send_group_dm. It does not state prerequisites or exclusions, so an agent gets no direct usage-vs-alternative direction.

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 say readOnlyHint=false, so the tool is a mutation, but the description adds nothing about side effects, membership implications, permissions, or failure cases. It does not contradict the annotations, so not a 1, but it provides no behavioral context beyond the annotations.

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

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

The description is a single, short sentence with no filler, so it is concise in a superficial sense. However, it is so sparse that it resembles under-specification rather than deliberate, well-structured communication.

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 tool with two parameters, the description covers the core action but leaves skip_log semantics, usage boundaries, and behavioral consequences unstated. Even with an output schema and annotations, the definition is not complete enough for an agent to call it with confidence.

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 offers no parameter explanation. channel_id is inferable from the resource, but skip_log is entirely unexplained, and the description does not compensate for the missing schema documentation.

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 clear action ('Join') and resource ('a channel'), and the required channel_id reinforces the purpose. It is not a tautology, but it does not explicitly distinguish itself from siblings like invite_users_to_channel or create_channel.

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 about when to use this tool versus invite_users_to_channel, create_channel, or list_joined_channels. The description simply restates the name and gives no context, prerequisites, or exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds value by explaining the default channel types and how to include DMs. This matches the read-only nature and does not contradict the annotations. The extra context about types improves transparency beyond the annotation flags.

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, no redundant phrasing. The primary purpose is front-loaded, and the parameter guidance is integrated efficiently in a single follow-up sentence. Every word 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?

For a simple listing tool with an output schema and all-optional parameters, the description covers the essential usage: what it lists, the default scope, and how to broaden it. It omits clarification on limit and exclude_archived, but these are minor given the tool's simplicity and the output schema presence. Complete enough for typical invocations.

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 only explains the 'types' parameter with a concrete example, leaving 'limit' and 'exclude_archived' undocumented. While their names are somewhat self-explanatory, the description does not fully mitigate the schema gap, especially for agents that rely on the description for all parameter meaning.

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

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

The description states a specific action ('List channels') with a precise scope (channels the authenticated user is a member of), clearly distinguishing it from sibling tools like get_channel_history (which fetches message history) or get_channel_id_by_name (which resolves IDs). 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?

It provides clear context on default behavior (public and private channels only) and how to extend to DMs via the types parameter, which helps agents decide when to call this tool. However, it does not explicitly mention alternative tools or give 'when not to use' guidance, so it stops short of a full 5.

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 indicate readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the description does not contradict the safety profile. However, it adds no extra behavioral context, such as whether the command is executed, what side effects it may have, or whether it requires special permissions.

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 short sentence with no wasted words and the key action is front-loaded. It is concise, though the brevity comes at the cost of useful detail that other dimensions require.

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, open-world mutation tool with four parameters and a sibling post_message, this description is too sparse. It does not explain what a 'command' is, how it differs from a normal message, or what side effects the caller should expect, leaving important context 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%, and the description only weakly illuminates the parameters: 'command' and 'channel' align with the command and channel_id fields, but text and skip_log remain completely unexplained. The description does not compensate for the missing schema parameter descriptions.

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

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

The description states a clear verb and resource: 'Post a command to a channel.' It is understandable and partially distinguishes this tool from the sibling post_message by using 'command' rather than 'message', but it does not explicitly contrast the two.

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 is given about when to use this tool versus alternatives such as post_message, send_dm, or send_group_dm. The intended usage is only implied by the tool name and the terse description, with no exclusions or conditions 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 readOnlyHint=false and destructiveHint=true, so no contradiction. The description adds a non-obvious behavioral detail: when blocks is provided, message serves as the plaintext fallback, and blocks must be a JSON string. This goes beyond the structured fields and helps the agent predict rendering behavior.

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 focused sentences with no filler. The core operation is front-loaded, and the Block Kit fallback detail is delivered in a compact, scannable way. Every sentence adds value.

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

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

For a tool with 7 parameters and 0% schema coverage, the description is adequate for the simple send-message case but incomplete for advanced usage. It explains blocks well but omits meaningful behavior for thread replies and link unfurling. The presence of an output schema reduces the need to describe return values, but the missing optional parameter semantics remain a 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 carries the burden of explaining parameters. It explains blocks and its relationship to message, but does not clarify thread_ts, skip_log, unfurl_links, or unfurl_media. Those parameter names may be suggestive, but an agent cannot reliably determine their semantics from the description 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 uses a specific verb and resource: 'Post a message to a channel.' It clearly distinguishes this from sibling DM tools like send_dm and send_group_dm, and from post_command by framing the operation as a message. The Block Kit mention adds meaningful scope without ambiguity.

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

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

The description makes the target context explicit ('to a channel'), so an agent can infer this is the right tool for channel messages rather than direct messages. It does not explicitly name alternatives or state when not to use it, but the channel scoping is sufficient for basic routing.

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 convey mutation and non-destructiveness, and the description adds context about stale-channel-cache scenarios. However, it does not explain what the refresh actually does internally, such as invalidation, refetching, or potential side effects beyond the cache.

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 short sentences with no filler. The primary action is front-loaded and the usage guidance is immediate.

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 cache refresh tool, the description and existing annotations fully enable an agent to decide when to invoke it. The presence of an output schema covers return-value expectations.

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

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

The input schema is empty and there are zero parameters, so the description has no parameter semantics to add; the baseline of 4 applies because nothing needs documenting.

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

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

The description clearly identifies the action ('Refresh the channel cache') and the resource affected, so an agent knows what the tool does. It is distinct from sibling refresh_user_cache because it targets the channel cache rather than the user cache.

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

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

It explicitly instructs when to use the tool: 'when new channels are created or if channel lookups are failing.' It does not name alternative tools or provide exclusion conditions, but the trigger context is clear and actionable.

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

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

The description discloses the mutation ('Clear the user cache') and adds a behavioral detail beyond the annotations: it 'Returns the number of cached entries cleared.' It does not contradict the readOnlyHint=false annotation, and it provides useful context about the operation's effect despite destructiveHint=false.

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, each earning its place: the first states the action, the second provides both usage context and the return value. There is no filler, redundancy, or unnecessary technical speculation.

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 cache-clearing tool with an output schema already present, the description is fully sufficient. It explains what the tool does, when to use it, and what it returns, leaving no meaningful gap for an agent to call it correctly.

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

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

The tool has zero parameters, so the description does not need to explain parameter behavior. Baseline for zero-parameter tools is 4, and the description correctly adds no irrelevant parameter information.

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 ('clear') and resource ('user cache'), and explicitly differentiates from the sibling refresh_channel_cache by naming the cache type. Even with the generic title, the first sentence gives an agent a clear, unambiguous 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 description gives an explicit trigger: 'Use this when user handles are outdated or if user lookups are failing.' This is clear contextual guidance, though it does not state exclusions or name an alternative tool for resolving lookups, so it falls just short of full when-not/alternatives coverage.

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

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

The description adds meaningful behavioral context beyond the annotations: the new_name is sanitized to lowercase with hyphens and no spaces, and the tool returns True/False to indicate success. This gives the agent a clear expectation of input transformation and result reporting.

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

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

The description is compact and well-structured with clear Args and Returns sections. Every line adds necessary information, and the primary purpose appears first.

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, annotations already convey destructiveness and mutability, and the description covers parameters, sanitization, and return behavior. It is missing only minimal context such as permission requirements or side effects of renaming, but nothing essential is absent for invoking 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%, and the description fully compensates by explaining both parameters: channel_id is the target channel ID with format C..., and new_name is the new name with sanitization rules. This is essential information that the schema completely lacks.

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

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

The description opens with a specific verb and resource: 'Rename a Slack channel.' This is unambiguous and tells an agent exactly what the tool does. It does not explicitly distinguish from sibling tools like create_channel, but the verb 'rename' is specific enough to avoid confusion.

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, and no mention of prerequisites or exclusions. The agent must infer usage from the name and description alone, which is insufficient for choosing between rename_channel and related channel 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?

Even with readOnlyHint and destructiveHint annotations already present, the description adds substantial behavioral detail: 24-hour cache, full workspace member list, search relevance ordering, and result fields. This gives an agent accurate expectations 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 four sentences with no filler: purpose, scope/cache, matching semantics, and result shape. Every sentence contributes meaningful information and the most important purpose is front-loaded.

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

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

Given the single parameter, presence of an output schema, and helpful annotations, the description covers everything needed to call the tool correctly: accepted input, scope, relevance order, result count, and returned fields. No critical operational detail is missing.

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

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

Schema coverage is 0%, so the description must carry the parameter meaning, and it does by explaining that query accepts a name, @handle, or email address. This directly compensates for the sparse schema, though it could be slightly more specific about exact matching behavior for handles or emails.

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

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

The description opens with a specific verb and resource: 'Resolve a Slack user ID from a name, @handle, or email address.' It clearly distinguishes this tool from channel-related siblings and similar lookup tools with the mention of full workspace member search and match format.

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

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

The description provides clear context on when to use it: whenever a user ID needs to be resolved from identifying information. It states the input formats and search scope, though it does not explicitly name alternatives or give when-not-to-use guidance, so it stops short of a 5.

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?

With readOnlyHint and openWorldHint already present, the description adds useful behavior: Slack search API usage, in:<channel> filtering, sort semantics for timestamp vs score, and default limit. This goes beyond the annotations without requiring redundant safety disclosure.

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

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

The description is compact and front-loaded, with a one-sentence purpose, a relevant API detail, and a clean Args list. Every line adds useful information without padding.

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

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

Given the output schema exists and annotations cover safety, the description is nearly complete for correct invocation. It lacks only explicit guidance on adjacent tools like search_messages or get_channel_history, but nothing needed to call the tool correctly is missing.

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

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

Schema description coverage is 0%, but the description compensates fully by explaining every parameter: channel_id, query, sort (with enum meaning), and limit (with default). This is essential because the schema titles alone would be insufficient.

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: search for messages within a specific channel. The Slack search API and in:<channel> filter make the scope explicit and distinguish it from general search_messages or get_channel_history.

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

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

The description clearly conveys this is for channel-scoped message search, which implies the right use case. It does not explicitly name alternatives like search_messages for cross-channel search, but the context is clear enough to route an agent.

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

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

Annotations already mark the operation as read-only and open-world, and the description adds pagination and limit semantics without contradicting those annotations. It does not disclose additional behavioral traits like sort behavior or result shape, though an output schema exists to cover return values.

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 concise sentences with no fluff. The first sentence states the core purpose and scope; the second adds concretely useful parameter behavior about limit and its default. 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?

For a simple three-parameter search tool, the description covers scope and limit, and the output schema exists to handle return values. However, it omits guidance on query format and sort semantics, and it does not mention relevant sibling tools for channel-scoped searches, leaving the agent with some inference to do.

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 schema's silence. It only clarifies the limit parameter, leaving query and sort without semantic explanation. The sort enum values 'timestamp' and 'score' are not elaborated, and query syntax is not addressed.

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

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

The description clearly states the action ('Search for messages') and the workspace scope, which distinguishes it from channel-scoped alternatives like search_channel_messages. However, it does not explicitly name or contrast siblings, so it stops short of full differentiation.

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 guidance is given about when to use this tool versus alternatives such as search_channel_messages or get_channel_history. The phrase 'in the workspace' implies a global search scope, but no exclusions or alternative conditions 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 convey that this is a side-effectful operation (readOnly=false, destructiveHint=true), lowering the burden. The description adds real behavioral detail beyond annotations: blocks must be a JSON string, rich_text blocks are supported, and message acts as the plaintext fallback. It does not cover unfurl behavior, but nothing contradicts 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?

Three sentences with no filler: the first states the action, and the next two concisely explain the optional block behavior and fallback semantics. Information is front-loaded and 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?

For a small side-effectful tool with an output schema and annotations, the core call semantics are covered: recipient, message text, optional rich formatting, and fallback behavior. The main gap is the undocumented unfurl parameters, but they have defaults and self-explanatory names.

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 does explain blocks (JSON string, rich formatting) and message (fallback role), but it says nothing about unfurl_links or unfurl_media, leaving those to inference from their names and defaults.

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 opening sentence, 'Send a direct message to a user', states a clear verb and resource. It implies a 1:1 user recipient, which helps distinguish it from channel-oriented tools, but it does not explicitly name siblings like post_message or send_group_dm.

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

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

The description implies the appropriate context by saying 'to a user' and gives useful formatting guidance, but it never states when to prefer this tool over post_message, send_group_dm, or post_command. There are no explicit exclusions or alternative routing cues.

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

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

Annotations already indicate a mutating, non-read-only action (destructiveHint=true, readOnlyHint=false), and the description adds a useful True/False return contract. It does not discuss side effects, unfurling behavior, or optional fields, so the transparency is adequate but not rich.

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

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

The description is compact and well organized: a one-sentence purpose, a short Args list, and a Returns line. Every sentence contributes, with no filler or redundancy.

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

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

Even with an output schema present, a 5-parameter tool needs more context than this. Three optional parameters are unexplained, no guidance is given for selecting this tool over send_dm, and the failure behavior beyond 'returns False' is not 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?

The description adds meaning for user_ids ('2+ user IDs') and message ('message text'), but schema description coverage is 0% and the optional parameters blocks, unfurl_links, and unfurl_media are completely undocumented. With low coverage, the description needed to compensate for these gaps and did not.

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 opening phrase 'Send a message to a group DM' gives a specific verb, resource, and scope, and 'multi-party direct message' distinguishes this from ordinary DMs. It does not explicitly contrast with siblings like send_dm or post_message, so it falls just short of a perfect score.

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

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

The requirement that user_ids must contain '2+' users implies this tool is meant for group conversations, giving some usage context. However, the description never states when to use this instead of send_dm for one-to-one DMs or post_message for channels, and it names no alternatives or exclusions.

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 readOnlyHint=false, so the description does not need to repeat that this is a mutating operation. It adds value by specifying the exact destructive nature ('replacing the current membership entirely') and the constraint that user_ids must contain at least one user. This goes beyond the annotation and gives the agent important behavioral context. It does not, however, mention any potential failure modes (e.g., invalid usergroup or user IDs), but that is not required given the annotation coverage.

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

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

The description is well-structured with an Args section and a Returns section. It is concise—only three sentences of core content—and every sentence provides necessary information: the action, parameter explanations, and return value. It is front-loaded with the primary behavior, then details, and ends with the return type. Nothing is redundant or extraneous.

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 two-parameter tool with a simple output (True/False), the description is entirely sufficient. It specifies the return type, explains both parameters, gives constraints, and points to the alternative for a different scenario. There is no missing information that an agent needs to correctly invoke the tool, especially given that annotations already supply the safety profile (destructive, not read-only).

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 full burden of explaining parameters. It does so effectively: usergroup_id is described as 'The usergroup ID (S...)' and user_ids as 'List of user IDs (U...)' with the critical constraint 'Must contain at least one user.' This adds format hints and constraints that the schema (which only provides types) does not convey, fully compensating for the lack of schema-level descriptions.

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

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

The description states a clear, specific action: 'Set the members of a Slack usergroup, replacing the current membership entirely.' It names the verb ('set'), the resource ('members of a Slack usergroup'), and the key behavior ('replacing entirely'). It also distinguishes from the sibling clear_usergroup by mentioning the alternative for removing all members, so an agent can immediately tell which tool to use.

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

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

The description explicitly says when to use this tool (to set/replace membership) and when NOT to use it: 'Must contain at least one user — use clear_usergroup to remove all members.' This gives a clear exclusion and points to the correct sibling for that case. No ambiguity remains about when to select this tool over alternatives.

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

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

Annotations already declare readOnlyHint=true, so no safety contradiction. The description adds the identity/authentication context but no additional behavioral details such as what the response contains or whether any session state is checked. With annotations available, this is adequate but not enriched.

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, compact sentence that fully states the tool's purpose. No filler or redundant information.

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

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

For a parameter-less, read-only tool with an output schema, the description is sufficient. It could mention that the tool returns identity information, but the output schema likely covers that; the current text is minimally 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?

There are zero parameters, so the baseline is 4. The description correctly implies no arguments are needed and does not attempt to document nonexistent parameters.

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

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

The description clearly identifies the tool's purpose with a specific action ('Checks') and resource ('authentication & identity'). It is distinct from the sibling tools, which focus on channels, messages, and user group operations.

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

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

The description implies the obvious use case—verify authentication status and identity—but does not explicitly state when to use it versus alternatives. For a standard whoami utility with no parameters, the absence of explicit guidance is acceptable but still leaves context implicit.

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