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

The readOnlyHint annotation already declares this as a safe read operation. The description adds that it returns token-owner fields and is intended for connection verification, but with an output schema present it does not need to detail return structure, and it omits any permission or rate-limit 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?

Two tightly written sentences, front-loaded with the core purpose and followed by a direct usage instruction. Every sentence earns its place with no repetition or filler.

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

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

For a zero-parameter authentication test with readOnly annotations and an existing output schema, the description provides everything needed: what it tests, what it returns conceptually, and when to use it. Nothing an agent needs in order to call it 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?

The tool has zero parameters, so there are no parameter semantics to document. The baseline for a no-parameter tool is 4, and the description does not introduce unnecessary parameter-related claims.

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 ('Test Slack authentication') and clarifies the scope as token-owner verification, distinguishing it from the sibling user-info tools. An agent can immediately understand that this is a connectivity/auth check rather than a general user lookup.

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

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

It explicitly states 'Use this to verify the connection is working,' giving clear when-to-use context. It does not name alternatives or exclusion cases, so it falls short of the top score, but the primary usage cue is unambiguous.

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

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

With no annotations, the description carries the full behavioral burden. It identifies the operation as a cancellation and the timing constraint, but does not disclose permission requirements, irreversibility, behavior if the message is already sent, or error conditions.

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 efficient sentence with no wasted words. The action and timing constraint are front-loaded and immediately useful.

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 with two fully documented required parameters and an output schema, so basic completeness is met. However, as an unannotated mutation tool, the description should provide more behavioral context such as reversibility and permission 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?

Schema description coverage is 100%, so both parameters are already well documented in the input schema. The description adds no additional parameter meaning beyond what the schema provides, which is acceptable given full schema coverage.

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

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

The description states a specific verb and resource: cancel a scheduled Slack message. It also adds the timing scope 'before it sends,' which distinguishes it from sending messages, though it does not explicitly name sibling 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 phrase 'before it sends' implies the use case: cancel a scheduled message prior to delivery. However, the description does not state when not to use the tool, what to do if the message already sent, or name any related alternative tools.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description needed to add the non-obvious behavior: result ordering, whether history is bounded by retention or bot membership, and pagination via cursor. It says none of that, adding zero context beyond the annotation.

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

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

A single front-loaded sentence with no filler or repetition. It is tightly written, though its brevity borders on under-specification given 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?

An output schema exists, so return values need no explanation, but for a six-parameter paginated history read the description omits pagination flow, ordering, and channel-type constraints (public, DM, group) implied by the channel_id hint. The structured fields are the only guidance an agent gets for a moderately complex tool.

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

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

Schema description coverage is 100%, so the timestamp windowing (oldest/latest/inclusive), limit cap of 1000, and cursor semantics are already fully documented. The description adds no extra meaning, which is the baseline 3 case.

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 (Get) and resource (message history) scoped to a Slack channel, so an agent knows exactly what it retrieves. It does not distinguish itself from siblings like slack_search_messages or slack_get_thread_replies, which is the only thing keeping it from 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 statement of when to use this tool versus slack_search_messages (keyword lookup), slack_get_thread_replies (thread expansion), or slack_list_channels. The reader must infer that this is the bulk-read path for a known channel ID 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, so the safety profile is covered. The description adds essentially nothing beyond that — no statement about what 'detailed information' includes, whether private/DM/GM channels (C/D/G) behave differently, or any 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?

One short, front-loaded sentence with zero filler. It is efficient, though the brevity reflects under-specification rather than deliberate 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 and the single parameter is fully documented, so much of the burden is already carried by structured fields. Still, a near-tautological sentence for a lookup tool leaves the agent without guidance on channel-type differences or relationship to sibling read tools.

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 a single parameter with 100% schema description coverage, including the C/D/G prefix hint, so the schema carries the full semantic load. The description adds no additional meaning about the channel_id, which is acceptable at 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?

States a specific verb and resource ('Get detailed information about a Slack channel'), which is clearly a single-channel lookup rather than a listing. It does not explicitly distinguish itself from close siblings like slack_get_channel_history or slack_list_channel_members, so differentiation is left implicit.

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 guidance on when to use this versus slack_list_channels, slack_get_channel_history, or slack_list_channel_members. There are no prerequisites or exclusions stated, so the agent must infer selection 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?

readOnlyHint=true already tells the agent this is a safe read; the description reinforces it by declaring metadata only and no content download. However, it discloses nothing about the surprising comments-pagination behavior implied by the page/count parameters, nor about rate limits or error cases.

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 the resource and its key constraint front-loaded. No filler, no redundancy.

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

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

An output schema exists, so return values need not be described, and the read-only safety profile is covered by annotations. What is missing is any explanation of the comments pagination parameters and their effect, which is the one non-obvious aspect of this tool.

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

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

Schema description coverage is 100%, so all three parameters are documented in the schema and the baseline is 3. The description adds no meaning beyond the schema, and in particular does not explain why a file-info tool takes comment pagination 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?

States a specific verb and resource (get metadata about a Slack file) and adds a scope qualifier ('no content download'). It is clearly distinct from list-style siblings like slack_list_files and from message-oriented tools, 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?

The parenthetical '(no content download)' implies a boundary but gives no explicit when-to-use, when-not-to-use, or alternative such as slack_list_files. An agent must infer the routing decision entirely.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. However, the description adds no behavioral context beyond the basic purpose: it does not mention completeness, pagination, limitations, or how the 'full' option changes results.

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

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

The single sentence is front-loaded and contains no wasted words. It is appropriately sized for a simple read tool, though its brevity contributes to gaps in guidance elsewhere.

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

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

For a simple read operation with full schema coverage and an output schema, the description provides enough to identify the tool and its target. It need not explain return values, but it could better distinguish itself from sibling reaction-listing tools.

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

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

Schema description coverage is 100%, so the input schema already documents channel_id, timestamp, and full. The description does not add meaning beyond the schema, which is acceptable at baseline 3 when the schema does the heavy lifting.

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

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 reactions for a specific Slack message.' This clearly identifies the operation, but it does not distinguish the tool from the sibling slack_list_reactions or clarify scope differences.

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 guidance on when to use this tool versus alternatives such as slack_list_reactions, nor does it state prerequisites or exclusions. Usage is only implied by the operation 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 declare readOnlyHint=true, so the safety profile is covered, but the description adds nothing beyond that: no disclosure that the result is paginated (limit/cursor), whether the parent message is included, or the ordering of replies. For a paginated list tool this leaves real behavioral questions unanswered.

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, but it is terse to the point of omitting useful context (pagination, parent-message inclusion) rather than optimizing information 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-value explanation is not required, and the schema covers all 7 parameters. However, for a tool with pagination and time-boundary filtering, the description could reasonably note the paged nature and thread-message scope; it is minimally viable rather than 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 100%, with every parameter including limit, cursor, oldest/latest, and inclusive fully documented inline. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Get replies in a Slack message thread'), which clearly delimits it from siblings like slack_get_channel_history or slack_search_messages. It does not name the closest alternative (channel history) to sharpen the distinction, 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 instead of slack_get_channel_history or slack_search_messages, nor any prerequisites (e.g., needing a parent message timestamp). Usage is only implied by the phrase 'in a Slack message thread'.

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 the safety profile is covered, but the description adds nothing beyond that — no note on what fields are returned, lookup failure behavior for an unknown ID, or whether deactivated users are included. Given the low bar set by existing annotations, it still contributes essentially no extra behavioral context.

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

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

A single front-loaded sentence with zero padding, which is well-structured. It is arguably too terse rather than verbose, but there is no wasted text to penalize.

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 means return values needn't be explained, but with a sibling like slack_get_user_profile in the same namespace, the definition leaves the primary ambiguity unresolved. For a lookup tool in a crowded sibling set, it is not complete enough to guide correct selection.

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 and 100% schema description coverage, the schema fully documents user_id including its prefix format. The description adds no meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ("Get information about a Slack user"), which is better than a tautology but adds no scope detail. Critically, it does not distinguish this tool from its close sibling slack_get_user_profile, so an agent cannot tell from the description which one returns profile-type 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?

There is no guidance on when to use this tool versus slack_get_user_profile or slack_list_users. The single sentence provides no context, prerequisites, or exclusions, leaving routing entirely to inference from the tool 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?

The annotations already declare readOnlyHint=true, so the description does not need to repeat safety. However, it adds no behavioral context beyond the annotations, such as scope of profile data, permission needs, or rate-limit 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 a single front-loaded sentence with no wasted words. It is concise, though its terseness contributes to the missing sibling differentiation.

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, the schema is fully described, and an output schema exists, so return values do not need explanation. Still, the description does not help an agent distinguish this from slack_get_user_info or clarify what profile information is returned.

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%, and both parameters are documented in the input schema. The description does not add meaning beyond the schema, so the baseline score of 3 applies.

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

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 a Slack user's profile information.' It is clear what the tool does, but it does not distinguish it from the sibling tool slack_get_user_info, which sounds nearly identical.

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 slack_get_user_info or slack_list_users. The agent must infer selection 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, so the safety profile is known. The description adds nothing further: no note on visibility restrictions (private vs public channels), pagination behavior, or permission requirements. With annotations carrying the safety bar, the description still leaves behavioral gaps unaddressed.

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. Appropriately sized for a simple list tool, though it verges on under-specified rather than lean.

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 and all parameters are documented in the schema, so the essentials are covered. However, for a tool whose results depend on channel type (C/D/G IDs imply channels, DMs, private groups), the description omits any behavioral context the agent would need to interpret results correctly.

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

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

Schema description coverage is 100%, so channel_id, limit, and cursor are fully documented in the schema. The description adds no additional meaning, which is acceptable given the schema does the work — 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?

States a specific verb and resource ('List members of a Slack channel'), which distinguishes it from siblings like slack_list_users and slack_list_channels. Clear, though it does nothing beyond naming the operation.

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

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

No guidance on when to use this versus slack_list_users or slack_get_channel_info, and no mention of prerequisites such as needing to be a channel member or having the right scopes. The agent must infer everything.

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 readOnlyHint annotation already establishes this is a safe read, and an output schema exists, so the bar is low. The description still adds nothing beyond that: it doesn't mention pagination behavior, the fact that archived channels and non-public types are excluded by default, or ordering of results.

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

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

A single short sentence with no filler and the key noun front-loaded. Brevity here crosses slightly into under-specification 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?

With annotations covering safety, a full schema, and an output schema, an agent can call this correctly. Still, defaults like excluding archived channels and the paginated nature of the results are only discoverable by opening the schema, so the description is minimally adequate rather than 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 100%, with limit bounds, type values, cursor meaning, and the archived default all documented in the schema. The description adds no extra semantic detail, so the baseline of 3 applies.

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

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

The description names a specific verb and resource ('List channels') scoped to the Slack workspace, so an agent can immediately tell what it returns. It does not, however, differentiate itself from nearby siblings such as slack_get_channel_info or slack_list_channel_members, which an explicit clause could have done.

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. channel info vs. member listing), nor of prerequisites or exclusions. Usage is only implied by 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?

The readOnlyHint annotation already establishes the safety profile. The description adds useful behavioral context by clarifying that results are metadata only and do not include file content, but it does not discuss pagination behavior, rate limits, or auth requirements beyond what the schema already shows.

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. The critical clarification about metadata-only scope is included 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?

With an output schema present and full parameter documentation, the description is nearly complete for a listing tool. It could be stronger by naming when to choose this over sibling file-access tools, but nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so every parameter is already documented with purpose and defaults. The description adds no extra meaning beyond the schema, which is acceptable given the schema does the heavy lifting.

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

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

The description states a specific verb (List) and resource (files) scoped to the Slack workspace, and clarifies that only metadata is returned. It clearly separates this from a content-download operation, though it does not explicitly distinguish itself from sibling tools like slack_get_file_info or slack_search_messages.

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 phrase 'List files in the Slack workspace', and the metadata-only note sets a boundary against content retrieval. However, there is no explicit guidance on when to use this tool versus slack_get_file_info, slack_search_messages, or the channel-specific listing siblings.

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

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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds nothing beyond that. It does not mention pagination behavior, what 'full' actually changes in the result, or how the default (authenticated user) is resolved, all of which would be useful 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 front-loaded sentence with zero filler. It is efficient, though the brevity comes at the cost of the guidance and behavioral detail noted above.

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, return values need no explanation, and the schema fully documents parameters. However, for a tool with pagination and a 'full' flag, the description should at least clarify scoping relative to slack_get_reactions, which it does not.

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 all four parameters are already documented in the schema, and the baseline is 3. The phrase 'made by a user' loosely maps to user_id but adds no semantics beyond what the schema states about 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?

States a specific verb and resource: 'List reactions made by a user.' The 'made by a user' qualifier distinguishes it from the sibling slack_get_reactions, which presumably returns reactions on a message, though the description never names that sibling 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?

No guidance on when to use this tool versus slack_get_reactions or other siblings, and no scenarios or prerequisites are given. The agent must infer the difference 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, so the safety profile is covered. The description adds that results are scoped to the authenticated user's own stars, which is useful context, but says nothing about ordering, pagination behavior, or result contents 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?

A single front-loaded sentence with zero filler. It is efficient but so terse that it omits any operational context, sitting just below the ideal for a list 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?

With an output schema, annotations, and full schema coverage, the mechanics are handled elsewhere. Still, the description leaves 'starred items' underspecified (what resource type, what ordering) for a tool an agent may choose among 16 siblings.

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?

All three parameters are fully documented in the schema (100% coverage), including defaults and the 1-100 bound for count. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb ('List') and resource ('starred items') with the scope 'for the authenticated user'. No sibling tool covers stars, so no differentiation is required, but the description does not clarify what kind of items (messages, files, channels) come back.

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 or when-not guidance, no mention of alternatives, and no note that pagination params control traversal. The only selection signal is the tool name itself.

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?

readOnlyHint=true already establishes the safety profile, so the description needn't restate it, but it adds essentially nothing beyond the name: no mention of pagination via cursor, no note on whether bots/deactivated users are included, no guidance on result size defaults. For a paginated listing tool this leaves behavior 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?

A single front-loaded sentence with zero filler. It is efficient, though the brevity is closer to under-specification than to disciplined concision.

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 and the params are fully documented, so the core contract is covered. What is missing for a paginated list tool is guidance on iterating cursors and on result scope (all workspace members vs. active only), which the description never addresses.

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 limit and cursor are fully documented in the schema, and the default 200 is stated there. The description contributes no additional semantics, which is acceptable at the baseline when the schema does the work.

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 ("users in the Slack workspace") makes the operation unmistakable. It does not, however, distinguish itself from nearby siblings such as slack_get_user_info, slack_get_user_profile, or slack_list_channel_members, so an agent must infer the boundary.

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 guidance and names no alternatives. With six sibling tools touching users or membership, the absence of a routing cue (workspace-wide listing vs. single-user lookup vs. per-channel membership) 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?

readOnlyHint=true already tells the agent this is a non-mutating search, so the annotation carries the safety profile. The description adds the Slack query-language capability, which is real behavioral context, but says nothing about result caps, permission scope (which channels are searchable), or pagination limits.

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 filler, with the core action front-loaded and the operator syntax immediately after. Nothing is repeated from the schema or annotations.

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 and parameters are fully documented, so the description needn't explain return values. It is nearly complete for a search tool, but omitting what is actually searchable (DMs? private channels? user token scope) leaves one meaningful gap for an agent deciding whether results will be authoritative.

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

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

Schema coverage is 100%, so all five parameters are self-documenting and the baseline would be 3. The description earns above baseline by explaining that the vague "query" field accepts Slack search modifiers with concrete examples (from:, in:, has:link, before:/after:/during:), which the schema does not convey.

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: "Search messages in the Slack workspace," which is distinct from history/thread siblings that retrieve by channel or thread. The workspace-wide scope is a useful differentiator, though it never names a sibling 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 modifier list implies the tool is for cross-workspace keyword lookup rather than per-channel retrieval, so an agent can infer when to use it over slack_get_channel_history. However, there is no explicit "use this when / use X instead" routing and no prerequisites 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?

With no annotations at all, the description carries the full behavioral burden and does the most important part: it discloses that the tool does not actually post immediately but calls chat.scheduleMessage with a ~3 minute cancellation window, which is a genuinely non-obvious side effect an agent would otherwise get wrong. It omits permission/scopes requirements, rate-limit behavior, and error semantics for an invalid channel_id.

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?

Front-loads the core action in one line, then devotes the remainder to the single non-obvious behavioral fact and its escape hatch. Every sentence earns its place; nothing is repeated from the schema.

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-value detail is unnecessary, and the key scheduling behavior plus the cancellation path are covered. The gap is the absence of any annotation coverage for a write operation — auth requirements and failure modes are left entirely implicit.

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

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

Schema description coverage is 100%, with text, channel_id, and thread_ts each documented inline, so the baseline is 3. The description adds no further meaning to any input parameter — the only identifier it mentions (scheduled_message_id) is a return value, not an input.

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 pair and resource ('Send or schedule a Slack message'), which is immediately distinguishable from read-only siblings like slack_get_channel_history or slack_search_messages. The scope is unambiguous 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?

Explicitly explains the default path (scheduled with a 3m delay), names slack_cancel_scheduled_message as the follow-up with the required scheduled_message_id, and states the opt-out (SLACK_ADD_MESSAGE_DELAY=0) for immediate posting. It stops short of stating when not to use this tool (e.g., for reactions, files, or thread reads), so it is not a full when/when-not routing statement.

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