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

Annotations already declare non-readOnly, idempotent, non-destructive. The description adds real value beyond them: the reaction is posted as the authenticated user and requires the reactions:write scope, which is auth context an agent needs. It stops short of noting side effects like notifications to the message author.

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?

Four tight lines, each doing work, with the critical 'AS THE USER' scoping front-loaded. The trailing newline and slightly clipped last fragment cost a little polish but nothing is wasted.

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

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

The output schema handles return values and annotations cover safety, but with 4 required parameters at 0% schema coverage the description leaves 'workspace' completely undefined and only indirectly defines channel_id. That omission matters for a call that will fail without a valid workspace.

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 parameter meaning. It explains ts ('message timestamp') and name ('emoji name without colons, e.g. eyes') well, but punts channel_id to another tool's docs and says nothing at all about the required 'workspace' parameter.

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

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

States a specific verb and resource ('Add an emoji reaction to a message'), names the underlying API operation, and clarifies the acting identity ('AS THE USER'). This cleanly separates it from slack_remove_reaction and slack_get_reactions in the sibling list.

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

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

Usage is implied by the operation but there is no explicit guidance on when to prefer this over alternatives or any preconditions beyond the scope requirement. An agent can infer the use case, but nothing is spelled out.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the risk profile is covered. The description adds genuinely useful context by naming the required scope (chat:write) and the API method, but says nothing about irreversibility, failure when the message already posted, or rate limiting.

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

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

A single front-loaded sentence with no filler; the parenthetical method/scope hint is terse and useful. It is efficient, though the tightness comes partly from under-specification rather than disciplined editing.

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

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

An output schema exists so return values need not be explained, but for a destructive, open-world mutation with 0% parameter documentation the description should say where the scheduled message ID comes from and what happens on failure. Those gaps leave the agent under-informed for a 3-required-parameter write operation.

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

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

Schema description coverage is 0% across three required parameters, so the schema offers only bare titles. The description does not clarify any of them — e.g. whether workspace is a name or ID, or what format scheduled_message_id takes — so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('Cancel a scheduled message') and even names the underlying API method, which cleanly separates it from slack_delete_message (deletes an already-posted message) and slack_schedule_message. It does not explicitly call out those siblings, so it stops short of a 5.

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

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

There is no when-to-use guidance: nothing tells the agent where scheduled_message_id comes from (presumably slack_list_scheduled), nor how this differs from simply deleting a message. Usage is only inferable from the tool name and the required ID parameter.

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 earns credit for adding what annotations cannot: the specific OAuth scopes required and the fact that the needed scope varies with the conversation type (channel/group/im/mpim). That is actionable pre-flight information an agent would otherwise only discover from an auth failure.

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 dense clauses with zero filler: the returned fields first, then the auth precondition. It is telegraphic to the point of being fragmentary, but every phrase carries information and the structure 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?

An output schema exists, so return values need no prose, and the auth scopes are covered. What remains missing is anything about the two required inputs — particularly how workspace is identified and whether channel_id type must be known in advance — which is material for a lookup tool that can't be called correctly without that.

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

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

Schema description coverage is 0% and neither parameter has a title beyond the raw field name, so the description carries the full burden and falls short: it never explains what 'workspace' means (slug, ID, or name) or that 'channel_id' must match the conversation type implied by the scopes. Only the loosest hint ('for the conversation type') gestures at the ID's semantics.

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

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

The description names the operation precisely by enumerating the fields returned (name, kind, topic, purpose, member count, read marker) and cites the underlying API call (conversations.info), which tells an agent this is a single-conversation lookup rather than a search. It does not explicitly contrast with siblings like slack_find_channel, but the field list makes the distinction inferable.

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

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

Usage is only implied: the mention of conversation-type-specific scopes hints that the caller must already know the conversation type, and by extension that this tool operates on a known channel_id. There is no explicit statement of when to prefer this over slack_find_channel or slack_read_channel, nor any when-not guidance.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered structurally. The description adds real value beyond them: the irreversibility warning, the ownership restriction that even an admin token cannot bypass, and the required OAuth scope. It doesn't cover response shape or error behavior, but that is partly handled by the output schema.

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 short sentences, each carrying distinct information: what it deletes, the ownership/auth constraint, and the irreversibility. Everything is front-loaded with zero 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?

Annotations and the output schema cover the safety profile and return values, so the description doesn't need to. However, with 0% schema coverage on three parameters, the description leaves a meaningful gap around how to identify the target message—the single most error-prone part of this call.

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

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

Schema description coverage is 0% and none of the three parameters (ts, workspace, channel_id) are explained in the description. Notably, 'ts'—the message timestamp identifier, which is a Slack-specific concept an agent could easily get wrong—is left entirely undocumented in both places.

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

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

States a specific verb+resource ('Delete one of YOUR messages') and names the underlying Slack API call plus required scope (chat.delete, chat:write). Ownership scoping is spelled out clearly. It doesn't explicitly differentiate from the closest sibling slack_edit_message, but the verb makes the distinction obvious enough.

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?

'Delete one of YOUR messages' establishes the applicable context, and 'Messages by others are refused even with an admin token' functions as an explicit when-not constraint. It doesn't point to an alternative tool, but the boundary is unambiguous for this operation.

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 annotations already flagging destructiveHint/openWorldHint, the description still adds real context: required OAuth scope, returned saved path, the <file_id>-<name> naming convention, and above all the atomic 'replace only once the new one is complete' overwrite semantics that explain the destructive flag. External files returning external_url rather than downloading is also disclosed.

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-loaded with the action and permission need, then the return value and the two constraints that actually change behavior. Dense but each clause earns its place; the line-broken layout is slightly harder to scan than a single tight paragraph.

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-shape detail is optional, yet the description still names the path and external fallback. Combined with the safety annotations, almost everything needed to call correctly is present; only the workspace parameter and the dest_dir default (~/Downloads/slack) are unaddressed.

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

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

Schema coverage is 0%, so the description must carry the load; it does for dest_dir (must live inside SLACK_FILE_ROOTS, matching slack_upload_file) and implies file_id is the Slack file identifier. The workspace parameter is left completely unexplained, which is the remaining gap.

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

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

States a specific verb and resource ('Download a Slack file by id to a local folder') and immediately scopes the behavior further by excluding external files such as Google Drive. It is clearly distinguishable from slack_upload_file and slack_file_info by naming the counterpart tool and the external_url fallback.

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 'needs files:read' prerequisite and the SLACK_FILE_ROOTS restriction tell the agent when calling will fail, and the external-file exclusion routes the agent to reading external_url instead. No explicit 'use this instead of X' framing, but the conditional guidance is strong.

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 mutation, idempotency, and non-destructiveness. The description adds useful context beyond annotations: ownership enforcement even for admins, required Slack scopes, and that formatting follows slack_send_message. It does not discuss rate limits or failure modes beyond ownership refusal.

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 three short sentences, front-loaded with the core action and immediately followed by the most important constraint. Every sentence adds useful 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?

Given the mutation behavior and annotations, the description covers safety and ownership well, and an output schema exists. However, with six parameters and 0% schema description coverage, it leaves important parameter semantics undocumented.

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

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

Schema description coverage is 0% for six parameters, so the description must carry the burden. It only clarifies that text is the replacement content and implies format follows slack_send_message, but it does not explain ts, channel_id, workspace, or allow_promise.

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: replace the text of one of YOUR messages. It distinguishes this from sending and deleting messages by stating the ownership constraint and naming the underlying Slack API methods.

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 clearly states the primary condition for use: only your own messages can be edited, and messages by others are refused even with an admin token. It does not explicitly compare against delete_message or send_message alternatives, but the ownership constraint gives strong practical guidance.

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

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

Annotations already cover the read-only/open-world profile, and the description adds real context beyond them: the required OAuth scope, the backing API method, and the notable behavior that every message sharing the file is returned (channel, ts, thread_ts). The external_url caveat for external files is a useful conditional 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?

A single dense sentence that front-loads the resource, scope requirement, and returned shape with no filler; the parenthetical field enumeration is compact and each clause 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?

With an output schema present, the description needn't restate return values, yet it usefully summarizes them; scope and safety are covered via annotation plus the 'files:read' note. The remaining gap is the undocumented workspace parameter, which is required.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning and largely does not. It clarifies that file_id is an identifier but not its format (Slack file id vs. permalink), and the required 'workspace' parameter is never mentioned at all — no hint whether it takes a name, subdomain, or id.

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 resource and operation ('File metadata by id'), names the backing API method (files.info), and enumerates returned fields, which distinguishes it cleanly from slack_list_files and slack_download_file. It stops short of explicitly naming those siblings, but the verb+resource pairing 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?

'needs files:read' gives a concrete prerequisite and calling it 'by id' implies you must already have a file id (e.g. from slack_list_files). However, it never names an alternative, so the agent must infer that slack_download_file is for content and slack_list_files is for discovery.

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, and the description adds genuinely new context: it excludes archived conversations, states which OAuth scopes are needed per type (including users:read for DM name resolution), and explains that 'refresh' reloads a cache — a non-obvious side effect. No return-format detail, but that is minor given the output schema.

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 dense sentences, front-loaded with the core action and no filler. The telegraphic style ('Needs channels:read/groups:read/...') is efficient but borders on cryptic for the permission clause.

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

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

Output schema exists so return values need not be explained, and permission/caching behavior is covered well. However, for a name-lookup tool with zero schema parameter descriptions, the absence of any statement about how 'query' is matched (substring, prefix, fuzzy) or what 'limit' controls leaves a real gap an agent needs to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully enumerates the valid 'types' values and the comma-separated format (no enums exist in the schema) and explains 'refresh' as a cache reload, but says nothing about 'query' matching semantics, 'workspace', or 'limit', leaving three of five parameters undocumented.

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

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

States a specific verb and resource ('Find non-archived conversations by name') with a scope qualifier (non-archived) and enumerates the conversation types it covers. An agent can tell this apart from slack_channel_info or slack_search, though no sibling is named explicitly.

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

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

Usage is implied by the scope ('by name', non-archived) but there is no explicit guidance on when to prefer this over slack_channel_info, slack_search, or slack_list_workspaces. The type/permission notes hint at configuration choices rather than routing decisions.

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 and openWorldHint, so the safety profile is covered. The description adds real value with the one-hour cache and the refresh-bypass behavior plus the required scopes per path. It stops short of describing result shape or lookup failure modes.

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 dense, front-loaded sentences with no filler; the main name-lookup path is stated first. The final line is truncated ('U.../W... uses users.info'), which slightly hurts readability.

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. Query and refresh semantics plus the cache/permission context are covered; only 'limit' and 'workspace' are left implicit, which is a minor gap for a 4-param tool.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It effectively explains what 'query' may contain (name, email, ID) and what 'refresh' does, but 'limit' and 'workspace' are never 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?

States a specific verb and resource ('Find people by name via cached users.list') and immediately distinguishes the underlying API path by query type (name vs email vs U.../W... ID). An agent can tell this is a user-lookup tool and not a generic search tool.

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

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

Gives explicit routing rules: exact email goes to users.lookupByEmail, U.../W... IDs go to users.info, everything else hits the cached users.list. It does not explicitly contrast with sibling slack_user_info, which is the closest ambiguity, so it falls 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the link opens in Slack and places replies in thread context, which is useful behavioral context, but it does not mention permission requirements or how the permalink is returned.

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

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

The description is a single front-loaded sentence with no filler. The parenthetical API method and thread-context note are useful, though the phrasing could be slightly tighter.

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 three required, undocumented parameters, the description is too thin. The output schema reduces the burden of explaining return values, but the lack of parameter semantics leaves an agent without enough detail to invoke the tool confidently.

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

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

Schema description coverage is 0% and the description does not explain the three required parameters—workspace, channel_id, or ts. It only implies that a message is being targeted, leaving formats and identifier semantics undocumented.

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

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

The description states a specific purpose: retrieve a permalink for a Slack message, identified by the underlying chat.getPermalink API method. It clearly distinguishes the action from sibling tools like slack_read_thread or slack_search_messages, though it does not explicitly name an alternative.

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

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

Usage is implied—call this when you need a link to a specific message—but there is no explicit guidance on when to prefer it over slack_read_thread, slack_search_messages, or slack_read_channel. No exclusions or alternatives are mentioned.

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, yet the description adds real behavioral context beyond them: the required scopes (reactions:read, users:read) and the fact that user lists can be partial, flagged by users_complete. The partial-data warning is exactly the kind of caveat annotations cannot express.

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, zero filler, front-loaded with what is returned and followed by the prerequisite scopes. Every clause carries 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?

Return values are covered by the output schema and safety by the annotations, and permissions are stated. But with three undocumented required parameters and no format guidance for ts, an agent can still mis-call it; the description is 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?

All three required parameters (workspace, channel_id, ts) have 0% schema description coverage, so the description carries the full burden. It does not explain any of them, and in particular gives no hint about the ts message-timestamp format, which is the one parameter an agent is most likely to get wrong.

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 message reaction names, counts and users') and names the fields returned, which separates it from the write-side siblings slack_add_reaction and slack_remove_reaction by implication. It stops short of explicitly contrasting itself with those siblings, so it is clear but not sibling-differentiated.

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

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

There is no explicit when-to-use or when-not-to-use statement and no named alternative. Usage is only implied by the name and the returned fields: an agent infers this is the read counterpart to add/remove reaction. That is implied usage, not guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful detail that nothing is transmitted and that the result field clean=true signals a pass — genuine 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?

Two short sentences with the non-sending guarantee and the key output flag front-loaded; nothing is wasted.

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

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

Trivial schema, an output schema that documents the return shape, and annotations for safety. The gist of the output flag is called out in the description; only the draft-parameter mapping is unspoken, which is minor here.

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?

A single required param named 'text' with 0% schema description coverage; the description only loosely implies it holds the draft content. The parameter is self-evident from its name, so this is adequate but adds little.

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 ('dry-run the style gate on a draft') and explicitly notes it does not send, which separates it from slack_send_message. It never names a sibling tool, but the intent 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?

'without sending' and 'dry-run' imply the use case is validating a draft before a real send, but no alternative is named and no explicit when/when-not condition is stated.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description isn't burdened with the safety profile. It still adds real value by disclosing the required OAuth scope ('Needs emoji:read') and what the results contain (URLs or alias targets) — both facts absent from the structured fields.

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

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

Two compact sentences with no filler; the core capability and matching rule come first, the permission caveat second. Every clause 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?

Output schema exists so return-value explanation isn't required, and the auth requirement plus match semantics cover the essentials for a simple read tool. The only real gap is the unexplained 'workspace' parameter.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does explain 'query' well (case-insensitive name substring, implicitly optional since default is empty), but says nothing about the required 'workspace' parameter, leaving that half of the schema undocumented.

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

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

States a specific verb and resource ('List custom emoji') plus the matching semantics ('case-insensitive name substring') and return shape ('URLs or alias targets'). It doesn't need sibling differentiation since none of the 29 siblings touch emoji, but it also names no alternative.

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

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

Usage is implied by the substring-matching note and the permission requirement, so an agent can infer this is for looking up custom emoji by partial name. However, there is no explicit when-to-use, when-not-to-use, or pointer to any alternative tool.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds valuable context beyond that: newest-first ordering, required OAuth scope, filter semantics, and pagination behavior ('the reply says how many pages there are') – all useful behavioral details not present in the schema.

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 ('List files, newest first') and then delivers scoping, filters, and pagination details in a dense but efficient manner. Every sentence contributes information, though the shorthand style is slightly terse.

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

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

Given an output schema exists, the description needn't explain return values. It covers ordering, filters, types, pagination, and auth scope, which is sufficient for an agent to invoke the tool correctly. The only notable omission is any mention of the required workspace parameter, but the schema marks it required and its meaning is conventional.

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 parameter meaning. It explains types (with a concrete list of values), page (1-based), channel_id, and user_id well, but completely omits the required workspace parameter and the count parameter, leaving significant gaps.

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

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

States a specific verb and resource ('List files, newest first') and names the underlying API method (files.list), so the operation is unambiguous. It does not explicitly differentiate from siblings like slack_search or slack_file_info, but the listing scope is clear enough to distinguish it.

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

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

Provides an important precondition ('needs files:read') and explains the intended filtering use case (by channel_id and/or user_id). However, it never states when to prefer this over alternatives such as slack_search or slack_file_info, leaving usage guidance implied rather than explicit.

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 safety is covered. The description adds two useful behavioral facts beyond that: results are ordered soonest-first and pagination is cursor-based per page. It does not say whether results are scoped to the required workspace or span all workspaces.

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

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

Two short sentences, front-loaded with what the tool returns and the ordering, with pagination in the trailing clause. No filler, though the line break inside the description is gratuitous and the sentence is slightly fragmented.

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 shape need not be described, and the read-only safety profile comes from annotations. What remains missing is a statement of how the required workspace parameter scopes the listing and what channel_id filters, which matters for a four-parameter tool.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It explains only the cursor, and usefully so (the API names it next_cursor, so the mapping avoids a wrong guess). The required 'workspace' parameter and the 'channel_id' and 'limit' parameters get no semantic explanation at all.

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

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

States a specific verb+resource: lists the caller's scheduled-but-unsent messages, and even names the underlying API method (chat.scheduledMessages.list). This implicitly separates it from slack_schedule_message and slack_cancel_scheduled, though no sibling is named explicitly.

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

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

The pagination instruction ('Pass next_cursor as cursor for the next page') gives real operational guidance, but there is no statement of when to use this versus slack_cancel_scheduled or slack_schedule_message, and no prerequisites are mentioned.

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 and openWorldHint, so the bar is lower; the description still contributes the required OAuth scope ('usergroups:read') and the behavioral effect of include_users on the payload. It leaves out pagination/result-size behavior, which matters for a list call.

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

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

Two short clauses, front-loaded with the action and its scope requirement last. Nothing is wasted, though the terseness comes at the cost of the missing workspace semantics rather than being purely efficient.

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

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

An output schema exists, so return values need not be described. However, for a two-parameter list tool the description leaves the required workspace parameter and any pagination/limit behavior unaddressed, which an agent needs before 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?

Schema coverage is 0%, so the description must carry parameter meaning. It explains include_users well (adds member IDs) but says nothing about 'workspace' — whether it takes an ID, a name, or a slug — which is the one required parameter.

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

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

States a specific verb and resource ('List user groups and counts') plus the optional enrichment ('include_users adds member IDs'). No sibling covers usergroups, so differentiation is implicit but unambiguous among the listed tools.

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

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

Usage is only implied by the object type; the description never says when to reach for this versus e.g. slack_find_user or slack_user_info, nor any preconditions beyond the scope. An agent can infer the intent but gets no explicit when/when-not guidance.

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

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

Annotations cover read-only and open-world, and the description adds real context beyond them: it discloses that it performs an auth.test call and that no extra scopes are required, which tells the agent about permission requirements. It stops short of describing failure behavior for invalid tokens.

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 compact sentence that front-loads the primary action and parenthetically qualifies the verification behavior — 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?

With no parameters and an existing output schema (so return values need not be explained), the description supplies enough to call it correctly. Minor gap: no hint about what aliases look like or what happens when a token is invalid.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a no-param tool 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 concrete verb+resource ('List configured workspace aliases') plus a secondary verification function ('verify token identities'), which no sibling tool covers. It is clearly distinguishable from the message/channel/file siblings, though the dual purpose (aliases vs. token verification) slightly blurs the primary 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?

Usage is only implied — an agent can infer this is a discovery/setup call before other Slack operations — but the description never says when to reach for it versus, say, slack_find_user or slack_channel_info, nor any preconditions.

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

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

Annotations already establish mutation, idempotency, non-destructiveness, and open-world behavior. The description adds useful material context beyond annotations: the conversations.mark operation and the exact OAuth scopes needed for channels, groups, IMs, or MPIMs.

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 focused sentence with the action front-loaded and the permission scopes compactly parenthesized. Every part contributes 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?

A simple, well-annotated write tool with an output schema, so return values need not be described. Still, the description leaves a notable gap around the required workspace parameter and does not clarify selection versus unread/read-channel 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It partially clarifies ts as the read-marker target and channel/DM as the conversation, but it never explains the required workspace parameter or the expected ts format.

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: moving a read marker in a channel/DM to a given ts, with the underlying conversations.mark API named. It is clear enough to distinguish from read/unread siblings, but it does not explicitly name an alternative to choose between.

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?

Implies when to use it by describing the read-marker move and listing required scopes per conversation type. However, it gives no explicit when-not guidance or comparison to related tools such as slack_unread.

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 safety profile is covered. The description adds value beyond that by naming the required scope 'canvases:read' and signaling that the entire content is returned ('full'), which annotations do not convey.

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

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

A single compact sentence with zero waste and the core action front-loaded. The only minor redundancy is re-explaining the content_type default and citing the API method, both of which the schema/annotations already imply.

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 readOnly hint plus the explicit scope requirement make it callable. The remaining gap is the unexplained workspace and canvas_id identity parameters, which an agent still has to infer.

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

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

Schema description coverage is 0%, so the description must compensate for three undocumented parameters. It only mentions the content_type options ('Markdown (default) or HTML'), which merely restates the schema enum/default, and says nothing about what workspace or canvas_id mean or where to obtain them.

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 ('Read') and resource ('full canvas content') and names the exact API call (canvases.getContent), so an agent knows precisely what it returns. No sibling tool reads canvases, so the operation is unambiguous against the surrounding message/search/file tools.

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

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

The description implies when to use it (when you need canvas content) and gives a precondition ('Needs canvases:read'), but it never addresses alternatives or exclusions. There is no guidance on when to prefer Markdown over HTML or how it relates to slack_read_channel/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 readOnly and openWorld, so the description is not carrying the safety burden. It still adds real context beyond annotations: the required OAuth scopes per conversation type (channels:history, groups:history, im:history, mpim:history) and users:read for name resolution, which tells an agent what auth failures may mean.

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

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

Two compact, front-loaded sentences: capabilities and pagination model first, prerequisites second. No filler, and the return-shape mention is brief rather than restating the output schema at length.

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?

Covers pagination model, auth scopes, and references return fields, with an output schema handling the return shape. However, for a 7-parameter tool with zero schema descriptions, the direction/ordering of messages and the meaning of limit and inclusive are unaddressed, which is a meaningful gap for correct invocation.

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

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

Schema description coverage is 0%, so the description should compensate for all 7 parameters; it only explains cursor and timestamp bounds (oldest/latest). It says nothing about limit semantics, what 'inclusive' toggles, or the workspace/channel_id role, leaving ambiguity for the remaining params.

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

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

States a specific verb and resource ('Read one history page') and scopes it with cursor/timestamp bounds, so an agent knows this is paginated channel history retrieval. It does not name or contrast with the closest siblings (slack_read_thread, slack_unread, slack_search_messages), so the differentiator is only 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?

'Read one history page' implies incremental pagination and distinguishes it loosely from bulk export, but there is no explicit when-to-use guidance versus thread reading, unread listing, or message search. Usage is inferable rather than stated.

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

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries real weight here: it discloses pagination semantics ('Returns complete=false while more remain'), the max_pages default and its stop condition, and the exact OAuth scopes required. It does not cover rate limits or ordering of returned messages, but the added context is substantial.

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 short clauses, no filler, and the pagination/default information is front-loaded where an agent will read it. Slightly dense with semicolons, but every clause carries information.

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

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

An output schema exists so return values needn't be spelled out, though the description usefully explains the complete flag anyway. For a 10-parameter paginated read with 0% schema coverage, a few parameters (inclusive, limit) remain unexplained, keeping it just short of complete.

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

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

Schema description coverage is 0% across 10 parameters, so the description must compensate. It meaningfully explains cursor, latest/oldest bounds, all_pages and max_pages, but leaves limit, inclusive, thread_ts, workspace and channel_id (including how to obtain a thread_ts) entirely undocumented.

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

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

States a specific verb and resource ('Read thread pages') and scopes it with cursor and timestamp bounds, which distinguishes it from slack_read_channel (channel-level) and slack_search_messages. It does not name a sibling alternative explicitly, but the thread-vs-channel distinction is clear from the resource named.

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

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

The description implies when to use it (when you need a thread's replies, possibly paginated), and gives some operational guidance ('all_pages stops at max_pages'), but never says when to choose this over slack_read_channel or slack_search_messages, nor any prerequisites for obtaining thread_ts.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered; the description adds genuinely new context by disclosing the required OAuth scope 'needs reactions:write'. It stops short of saying whether removing a non-existent reaction errors or silently succeeds, which is the one behavior an agent would still want.

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

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

One sentence, operation front-loaded, parenthetical metadata trailing. Nothing wasted and nothing that could be reordered for better scanning.

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

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

An output schema exists, so return values need no explanation, and the scope requirement is a nice addition. But for a 4-required-parameter mutation tool with 0% schema coverage, the definition is thin: timestamp format and the self-only restriction deserve explicit statement.

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 all four parameters are required, yet the description says nothing about any of them. The critical gap is 'ts', whose Slack timestamp format ('1700000000.123456') is non-obvious and undocumented anywhere, and 'name' vs 'channel_id' vs 'workspace' distinctions are left entirely to inference.

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 ('Remove the user's emoji reaction from a message') and names the underlying API method, which pins down the operation precisely. It does not explicitly name slack_add_reaction as the counterpart, but the verb 'remove' makes the direction obvious.

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 'the user's emoji reaction' usefully implies scope: only the authenticated user's own reaction can be removed, not someone else's. However, there is no explicit when-to-use framing, no mention of what to do if the reaction is absent, and no named alternative such as slack_add_reaction.

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 a non-readOnly, open-world, non-idempotent write; the description adds genuinely new behavior: it posts as the user under chat:write, the post_at must carry a timezone, and the horizon is capped at 120 days. The 120-day limit and identity/scope disclosure are exactly the kind of pre-call constraints annotations cannot convey.

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

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

Three sentences, none wasted: the action and identity come first, the tricky time parameter second, and the delegation pointer last. The dense parentheticals carry real information rather than 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?

Annotations cover the safety profile and an output schema exists, so the description need not explain returns. It fills the highest-risk gaps (identity, timezone format, scheduling horizon) but leaves the channel/thread/format semantics to a sibling's description.

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

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

Schema description coverage is 0% across 8 parameters, but post_at — the only non-obvious one — gets a concrete format example, timezone requirement, unix-seconds alternative, and the 120-day cap. The remaining seven (text, channel_id, workspace, format, thread_ts, allow_promise, reply_broadcast) are deferred entirely to 'as in slack_send_message,' which requires opening another tool's docs.

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 ('Schedule a message'), names the underlying API (chat.scheduleMessage) and scope (chat:write), and stresses AS THE USER. It is distinguishable from slack_send_message by the scheduling verb, though the distinction is left implicit rather than stated as a contrast.

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?

Scheduling versus immediate sending is implied by the verb, and the description points to slack_send_message for 'other arguments and the style gate.' It never explicitly says when to pick this over slack_send_message or how it relates to slack_list_scheduled/slack_cancel_scheduled, so the agent must infer the workflow.

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

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

Annotations already cover the read-only and open-world profile, and the description adds genuinely new context: the exact OAuth scopes needed and the token-type caveat. It also mentions cursor-based pagination. It stops short of describing result shape or rate-limit behavior, but with annotations and an output schema present that is a minor gap and 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?

Two short sentences with no filler, and the default-behavior fact is front-loaded. The density of unexplained jargon ('RTS') and the run-on scope list reduce clarity per word.

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?

Return values need not be explained given the output schema, and scope/permission needs are covered. But for a six-parameter tool with zero schema descriptions, the missing explanation of workspace and limit plus the absent sibling differentiation leaves real gaps.

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

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

Schema description coverage is 0%, so the description carries the burden for six parameters. It usefully explains the effective defaults for the type-list parameters (messages in public_channel) and names the cursor, but leaves workspace and limit completely unexplained and does not clarify the query syntax.

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?

It states a search verb and mentions that content type lists default to messages in public channels, so the general purpose lands. But the opaque acronym 'RTS' is never expanded, and the description never distinguishes this tool from the sibling slack_search_messages, which an agent will have to disambiguate on its own.

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 scope requirements (search:read.public required, others optional) give useful preconditions for selecting this tool, and the note that user tokens need no action_token is real guidance. However, there is no statement of when to prefer this over slack_search_messages or the narrower read/search siblings, and no 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 cover read-only and open-world behavior, and the description adds real value on top: it names the exact scopes required (search:read, users:read) and notes that author names are cached, which warns of a degradation mode. Pagination is signposted via the total/page/pages return note, though rate limits and result-window limits are not mentioned.

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 tight sentences that lead with the action and follow with operational constraints; minimal waste. Minor redundancy in restating the count 1-100 range that the schema already enforces via minimum/maximum.

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 prose, and auth is covered. But for an 11-parameter query tool with zero schema descriptions, the description leaves most filter semantics undefined, and it never explains how this differs from the sibling slack_search.

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

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

Schema description coverage is 0% across 11 parameters, so the description carries the full burden and largely fails it: only count is clarified (1-100), while has, from_user, in_channel, after, before, page, sort, and sort_dir are never explained or given expected formats. The generic "optional filters" phrase does not compensate for that gap.

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

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

The description gives a specific verb+resource ("Search visible messages") plus the query mechanism ("raw Slack query and optional filters") and return shape. It does not, however, differentiate itself from the sibling slack_search, leaving an agent to guess which search entry point 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?

There is no guidance on when to choose this over slack_search, slack_read_channel, or slack_read_thread, and no statement of preconditions beyond the auth scopes. The phrase "optional filters" implies they exist but never says when to apply them.

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 only declare the generic write/open-world/non-idempotent profile; the description adds genuinely non-obvious behavior: the message posts under the user's identity with no app badge, a style gate actively rewrites or blocks output unless SLACK_STYLE_GATE=off, promises are blocked unless allow_promise=true, and unfurls are off by default. These are exactly the side effects an agent must know before calling.

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-loaded with identity and scope, then per-parameter guidance in a tight run of fragments; little is wasted. The style-gate block is dense and reads as one long sentence chain rather than clearly delimited rules, which slightly slows scanning.

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 needn't be explained, and all six non-obvious parameters are covered. What's missing is failure behavior: what an agent sees when the style gate rejects a message, and whether any rate limiting applies to high-volume posting.

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 full burden and does: it defines workspace provenance, the three channel_id id classes including the U→DM case, thread_ts for threaded replies, reply_broadcast as 'also show in channel,' format options with length/charset differences, unfurl_links default, and allow_promise semantics. Only 'text' is left implicit, which is self-evident.

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 ('Post a Slack message') plus the distinguishing scope 'AS THE USER (no app badge), via personal user token,' which separates it from sibling send paths. An agent can tell this apart from slack_schedule_message or slack_edit_message without inspecting schemas.

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?

Gives concrete routing guidance: workspace must be an explicit alias from slack_list_workspaces, channel_id accepts C/G/D ids or a U id to open a DM (requiring im:write), and reply_broadcast only applies with thread_ts. It stops short of explicitly naming when to prefer slack_schedule_message over an immediate send, so it's strong context without full alternative 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?

Goes beyond the annotations by disclosing the required OAuth scope (users.profile:write), that the status is visible to everyone in the workspace, and what clearing/expiry semantics do to existing state. The annotations already cover idempotency and non-destructiveness, so this added context is the right kind of value for a 4.

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-loaded with the action and API method, then parameter notes in short clauses; no filler. The parenthetical scope note interrupts slightly but still 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?

An output schema exists so return values need no explanation, and the mutation's safety profile is covered by annotations. But for a five-parameter tool, the unexplained workspace and allow_promise parameters leave a real gap an agent may stumble on in multi-workspace setups.

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 parameter meaning, and it does explain text (empty clears it, style gate applies), emoji (format like palm_tree), and expires_in_minutes (0 = until changed). However, the required workspace parameter and allow_promise are never explained, leaving two of five parameters opaque.

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 ("Set the user's Slack status") plus the underlying API method (users.profile.set), so the action is unambiguous. No sibling tool sets a status, so it is clearly distinguished from the listing/search/read siblings.

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

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

Gives useful operational rules ("Empty text and emoji clear it", "expires_in_minutes: 0 keeps it until changed") but never states when an agent should set status versus, say, sending a message or reacting. There are no explicit alternatives or when-not-to-use conditions.

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 and openWorldHint, so safety is covered. The description adds genuinely useful behavior beyond that: it is capped at 20 conversations, it is backed by conversations.info plus conversations.history, and count stops at limit with has_more signaling truncation. Only the per-channel return shape is left unstated, and an output schema 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 tight sentences with the core purpose front-loaded and the API caveat placed where it matters. The parenthetical API call list is slightly noisy but short enough to earn 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?

With annotations covering the safety profile and an output schema covering return values, the remaining burden is small. The one real gap is the undocumented workspace parameter, which leaves an agent guessing at required input semantics.

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 parameter meaning. It does explain channel_ids indirectly via 'up to 20 channels/DMs' and explains limit's truncation semantics, but the required workspace parameter is never mentioned and the 20-conversation cap is not tied explicitly to the array.

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

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

The description gives a specific verb and resource: it counts messages that arrived after the read marker per channel/DM, which separates it from slack_read_channel and slack_search. It never names a sibling explicitly, so the differentiation is left to inference, but the purpose itself 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 communicates a real usage constraint: there is no full unread inbox like the app, so the caller must name channels. That implies when the tool is appropriate, but it never states when to prefer slack_read_channel or slack_search instead, or what to do when the channel set is unknown.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the description's job is to add context: it does, disclosing that the file is uploaded as the user, that a self-DM requires im:write, that filesystem access is sandboxed to SLACK_FILE_ROOTS, and that the message style gate applies. It omits size limits and failure behavior, so not a 5.

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

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

Front-loads the action, then lists per-parameter guidance in a compact line-per-parameter layout with little waste. The cross-reference to slack_send_message's style gate assumes prior knowledge of a sibling, which costs a bit of clarity.

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 mutating, multi-parameter upload tool with an output schema and annotations, the description covers identity, scoping, threading, and path sandboxing. Gaps remain around the undocumented workspace/allow_promise parameters and any size or failure constraints, but nothing critical to calling it 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%, so the description must compensate and it largely does: channel_id formats, thread_ts semantics, file_path constraints, title default to filename, and initial_comment via the style gate. Two of seven parameters, workspace and allow_promise, are never explained.

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 (upload a local file to a Slack channel/DM) plus the identity it acts under (AS THE USER) and an optional comment. It is trivially distinguishable from slack_download_file and from the message-editing siblings.

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

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

Gives concrete usage conditions: channel_id accepts C/G/D or a U id for a DM (with im:write caveat) and thread_ts turns the upload into a thread reply. It also states exclusions (hidden files and ~/Library are refused, path must be inside SLACK_FILE_ROOTS). It stops short of naming an alternative tool or when-not to upload.

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

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

Annotations already cover read-only and open-world behavior, but the description adds genuinely new operational context: which OAuth scopes are required, and specifically that the email field needs an extra scope. That scope-dependency is exactly the kind of thing an agent cannot infer from schema or annotations, though it says nothing about error behavior on missing scopes.

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, the returned-fields summary front-loaded and the permission caveat second. Efficient, with no filler; the only weakness is that the scope note is terse enough to be slightly cryptic about what happens without the email scope.

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

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

An output schema exists so return values need not be explained, and the description usefully enumerates the main fields anyway. However, with 0% schema description coverage on two required parameters, the definition leaves a material gap about how to supply user_id and workspace.

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 both parameters, but it mentions neither user_id nor workspace. An agent gets no hint about user ID format (U-prefixed vs name) or what 'workspace' identifies — a real gap for a 2-required-param tool.

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 resource (a user's profile fields) and names the underlying API (users.info), so an agent knows this is a profile lookup. It does not explicitly contrast with the sibling slack_find_user, which is the most likely point of confusion, so it stops short of a 5.

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

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

The description gives a prerequisite (users:read and users:read.email) but never says when to use this versus slack_find_user or other user-related siblings. Usage is implied by the field list rather than stated.

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