Slack MCP Server

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

Annotations already provide destructiveHint and idempotentHint. Description adds no further behavioral context beyond the annotation.

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

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

Single sentence, no fluff, directly states the action.

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

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

For a simple action tool, the description and schema together cover the necessary info. Lacks guidance on when to use, but not critical for such a tool.

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

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

Schema coverage is 100% with parameter descriptions. The description does not add additional meaning beyond the schema.

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

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

The description clearly states the verb (add), the resource (emoji reaction), and the target (message). It distinguishes itself from sibling tool slack_remove_reaction.

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

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

No guidance on when to use this tool versus alternatives, no prerequisites mentioned, and no context for appropriate usage scenarios.

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, openWorldHint=false, idempotentHint=false, and the description adds substantial context on top: it runs locally against your own session with no hosted account or server-side model, and it discloses exactly how the `continuity` block is derived (phrase and reply-count rules over the same messages, with matched text and a permalink per row). That is real behavioral disclosure beyond the structured fields.

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

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

The core action is front-loaded in the first clause, and the dense sentences each carry distinct information (scope, thread expansion, return shape, continuity derivation, output_contract usage). It is one long paragraph and slightly overstuffed, but there is little pure 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 output schema, the description carries the return-value burden and does so thoroughly: it names `signals`, `continuity`, `conversations`, and the `output_contract` keys, and even instructs how to compose the summary. An agent has everything needed to call it and consume the result.

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

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

Schema coverage is 100% with only two parameters, so the schema already documents both. The description restates `since` and the cadence-window defaults, which the schema also covers, adding little new syntax or format detail. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb+resource ('Catch up on a saved workflow profile') and enumerates exactly what it does: reads the profile's channels, pulls messages since a window, expands threads, and returns structured evidence. It is clearly distinguishable from siblings like slack_conversations_unreads (unfiltered unreads) and slack_conversations_history, and it names the profile tools it depends on.

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

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

Gives clear context: operates on a profile saved via slack_workflow_save, listed with slack_workflows, and falls back to 'everything currently unread' when the profile names no channels. It does not, however, explicitly state when to prefer this over a plain unread/history/search call, so the routing decision is inferred rather than spelled out.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds only the name-resolution trait, which is already exposed via the resolve_users parameter; it says nothing about pagination, rate limits, or the provenance/labelling behaviour that dominates 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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though arguably too terse for an eight-parameter read tool with a non-trivial security-related mode.

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 output schema and eight parameters, the description should carry more: how history is windowed/paginated, default ordering, and the behavioural consequence of the provenance modes. None of that appears, so an agent must reverse-engineer usage from the schema alone.

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

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

Schema coverage is 100% and every parameter (limit, oldest, latest, provenance, resolve_users, include_all_metadata, include_rich_message_fields) carries its own description, so the schema does the heavy lifting. The description adds no timestamp format, pagination, or provenance guidance beyond what is already there, making the baseline 3 correct.

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

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

The description names a specific verb and resource (get messages) and bounds the scope to a channel or DM, plus a distinguishing post-processing trait (user names resolved). It does not, however, differentiate itself from near-neighbours like slack_get_full_conversation, slack_get_thread, slack_conversations_unreads, or slack_search_messages.

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

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

There is no statement of when to use this over slack_get_full_conversation, slack_get_thread, or slack_search_messages, and no exclusions or prerequisites. The only routing signal an agent gets is implicit in the phrase 'channel or DM'.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, signaling state change and safe retry. The description adds no additional behavioral context beyond what annotations provide, such as side effects on unread badges or permission requirements.

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

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

A single sentence that is front-loaded and contains no extraneous words. It efficiently conveys the tool's purpose.

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

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

Given the tool's simplicity (2 required params, no output schema, clear annotations), the description provides enough information for an agent to use it correctly. Context like the timestamp parameter's inclusive nature is clear from the schema 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 100%, so both parameters are well-documented in the schema. The description does not add meaning beyond what the schema already provides for channel_id and timestamp.

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

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

The description clearly states the action (mark as read) and the scope (up to a specific message timestamp). It distinguishes from sibling tools like slack_conversations_unreads (unread count) and slack_conversations_history (history retrieval).

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

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

The description implies usage for marking conversations as read but lacks explicit guidance on when to use versus alternatives like slack_catch_me_up (which might batch mark) or when not to use it.

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

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

Annotations cover readOnlyHint, idempotentHint, openWorldHint. Description adds sorting behavior (by unread count) but lacks details on pagination, rate limits, or result format. With annotations present, this is marginal.

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?

Single sentence, direct, no filler. Efficiently conveys core purpose and key behavioral trait (sorting).

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?

No output schema, so description should hint at return format. It states what is returned (channels and DMs with unread messages) but does not specify fields or structure. Adequate for a simple read tool, but could be more 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 coverage is 100% with both parameters described. The description reinforces the sorting context but adds no new parameter-level detail. Baseline 3 is appropriate.

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

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

The description clearly states the action (Get) and resource (channels and DMs with unread messages), and distinguishes from siblings like slack_conversations_history by specifying 'unread' and sorting by count.

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

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

No explicit when-to-use or alternative guidance. The description implies usage for fetching unread conversations, but does not contrast with related tools like slack_conversations_history or slack_search_messages.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds that it can save to a file, which is useful context beyond the annotations, but it omits the default/max message caps (2000/10000) and pagination behavior that materially affect a 'FULL' export.

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

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

Two short sentences, front-loaded with the core capability and the optional file output. No wasted words, though the brevity leaves capability detail to the schema.

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

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

For a 9-parameter export tool with no output schema, the description covers the headline capability but omits essential operational context such as defaults, truncation risk at max_messages, and where files land (schema covers the path). Adequate but noticeably thin.

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

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

Schema description coverage is 100%, including detailed descriptions for oldest/latest, max_messages, output_file, and the provenance enum, so the schema does the heavy lifting. The description adds nothing beyond the schema, which is the expected baseline of 3 under full coverage.

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

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

States a specific verb and resource: export full conversation history including messages, threads, and user names, plus optional file saving. It is clearly distinguishable from lightweight siblings like slack_conversations_history by the word 'FULL' and the export framing, though it never names an alternative explicitly.

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

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

No guidance on when to prefer this over slack_conversations_history, slack_get_thread, or slack_search_messages, and no mention of limits or prerequisites. The only implicit signal is 'FULL' and 'export', which an agent must infer selects this for bulk dumps.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description itself adds no behavioral context such as pagination, ordering, or provenance implications, which are material given the complex 'provenance' parameter that holds send_message behavior.

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

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

A single short sentence that is front-loaded with the action and target. There is no filler or repetition, which is ideal given the schema carries the rest of the details.

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 5 parameters, one enum, and a non-trivial provenance behavior that can affect whether send_message is blocked, the description gives no additional context. With no output schema, the agent gets no guidance on return shape, ordering, or pagination. The definition is under-specified for correct invocation in operational contexts.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters, including the enum and its detailed semantics. The description adds no parameter meaning beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('Get all replies in a message thread') that clearly maps to the tool name and distinguishes it from siblings like slack_conversations_history. However, it doesn't differentiate from slack_get_full_conversation explicitly, leaving the agent to infer the difference.

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

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

No when-to-use, when-not-to-use, or alternative tool guidance is provided. The agent must infer from the name and description alone that this is for threaded replies and not for full conversation retrieval.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and openWorldHint, so the tool's safety and idempotence are clear. The description adds that it checks token validity and auth status, which aligns with annotations but does not provide additional behavioral context beyond them.

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

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

Single sentence that is concise and front-loaded. Every word is necessary; no superfluous content.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is adequately complete. It explains the core functionality without omission.

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?

No parameters are defined; schema coverage is 100% as there are none. The description does not need to add parameter semantics, and its simplicity is appropriate.

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

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

Description clearly states it checks Slack token validity and authentication status. It is a specific verb+resource pair. However, it does not explicitly distinguish from the sibling tool 'slack_token_status', which may serve a similar function.

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

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

No guidance on when to use this tool versus alternatives like 'slack_refresh_tokens' or 'slack_token_status'. The description only states what it does without context on appropriate usage scenarios.

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 indicate read-only and idempotent behavior. The description adds that it uses cached DMs by default and can be slower with rate limits when discovering all DMs, which is valuable beyond annotations.

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

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

Two sentences, front-loaded, no wasted words. Efficient and clear.

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

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

The description covers key behaviors and caching, but lacks details on return format or pagination beyond the limit parameter. With no output schema, more detail on the response structure would help completeness.

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

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

Schema coverage is 100%, so the description adds little extra meaning about parameters. It does clarify the caching behavior related to discover_dms, but overall the schema already documents parameters adequately.

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

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

The description clearly states the tool lists DMs and channels with resolved user names. It distinguishes from sibling tools like slack_get_full_conversation or slack_conversations_history by focusing on the list of all conversations.

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 mentions cached DMs by default and the discover_dms parameter for slower full discovery, providing context on when to use each. However, it does not explicitly state when not to use this tool or mention alternatives.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds minimal behavioral context beyond 'all users' – no mention of pagination behavior, user status (active vs deactivated), or rate limits. Description carries no contradiction with annotations.

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

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

Single sentence, directly states purpose. Efficient but could include a brief usage hint without harming conciseness.

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

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

With no output schema and multiple sibling tools, description lacks critical context: what 'all users' includes (bots, deactivated?), pagination details, and expected output structure. Bare minimum not fully met.

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

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

Schema description coverage is 100% for the single 'limit' parameter, which explains maximum and pagination. Description adds no additional meaning beyond schema, so baseline 3 is appropriate.

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

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

Description 'List all users in the workspace' clearly specifies verb (list) and resource (users), and includes scope (all, workspace). It distinguishes from siblings like slack_users_info (specific user) and slack_users_search (search), making purpose 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?

No guidance on when to use this tool versus alternatives such as slack_users_info or slack_users_search. Missing context on limitations or exclusions, leaving agents to infer appropriate usage.

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

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower; the description still adds genuinely useful non-annotation context by disclosing that it reaches into local Chrome state and is macOS-only. It stops short of describing failure behavior when no Chrome session 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?

A single sentence with the action front-loaded and the platform/prerequisite constraints tucked into a compact parenthetical. 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?

For a zero-parameter, no-output-schema tool, the description covers what it does, how it does it, and where it works, which is most of what an agent needs. It omits what happens on failure (e.g., Chrome not running or no Slack session) and any note that other operations may need re-auth afterward.

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 no per-parameter semantics to convey; baseline 4 applies. The description correctly implies there are no inputs to supply.

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 ('force refresh tokens') plus the actual mechanism ('extracting from Chrome'), which is far more informative than the name alone. It is distinguishable from slack_token_status (which likely just reports state) and slack_health_check, though it never names those siblings explicitly.

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

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

The parenthetical gives a precondition (macOS, signed into Slack in Chrome), which implies when the tool can run, but there is no statement of when an agent should prefer this over slack_token_status or slack_health_check, and no guidance for non-macOS environments.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a modifying operation. However, the description adds no additional behavioral context (e.g., that only your own reactions can be removed, or that removing a non-existent reaction might silently succeed). The description does not contradict annotations.

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

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

The description is a single, concise sentence that conveys the essential purpose without any wasted words. It is appropriately front-loaded and easy to parse.

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

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

For a simple removal tool with 3 required parameters and no output schema, the description is adequate but not fully complete. Missing details like 'only your own reactions' or 'idempotent: safe to retry' would improve completeness. The annotations fill in some gaps (destructive, idempotent).

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add any meaning beyond what the schema already provides for the three parameters (channel_id, timestamp, reaction). No additional guidance on format or constraints.

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

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

The description clearly states the verb ('remove') and the resource ('emoji reaction from a message'), making the purpose immediately understandable. It effectively distinguishes from the sibling tool 'slack_add_reaction'.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., no mention of only being able to remove your own reactions, or that the reaction must exist). An agent would have no context for appropriate use.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered structurally. The description adds nothing beyond them — no note on result volume/caps, no mention that this hits Slack's search index (which has indexing lag/limited retention), and no hint about the provenance/labelling behavior governed by the schema's provenance parameter.

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

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

A single efficient sentence with the resource and scope front-loaded and zero filler. It is arguably too terse to be fully 'appropriate', but nothing in it is wasted.

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

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

With rich annotations and 100% schema coverage, the description is minimally sufficient to call the tool correctly. However, for a search tool with no output schema it omits anything about result shape, pagination/truncation at the 100-result cap, or how it relates to the conversation-scoped retrieval 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 100%, so all four parameters (count, query, provenance, include_rich_message_fields) are already documented in the schema, including Slack query syntax and the provenance tightening rules. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

Specific verb+resource ('Search messages') with an explicit scope ('across the Slack workspace'), so the agent knows this is a cross-workspace text search rather than a per-conversation fetch. It stops short of distinguishing itself from siblings like slack_conversations_history, slack_get_full_conversation, or slack_catch_me_up.

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

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

The description gives no when-to-use guidance, no prerequisites, and never names an alternative among the many overlapping retrieval siblings (slack_conversations_history, slack_get_thread, slack_catch_me_up). The only routing signal is the implicit 'across the workspace' scope, which the agent must infer.

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=true, idempotentHint=false, and openWorldHint=true, covering the safety profile. The description adds nothing beyond that: it doesn't warn that sends are irreversible or that the provenance mechanism can hold a send, even though that is the most consequential behavior an agent needs to reason about. No contradiction with annotations.

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

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

A single short sentence with the action and target front-loaded and zero filler. It is efficient, though it leans on the schema for all the substance.

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

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

For a destructive, non-idempotent write tool with five parameters and no output schema, the description is thin: it says nothing about hold/release semantics, permission requirements, or when to prefer an alternative action. Annotations and the rich schema carry most of the burden, leaving the description at the minimum viable level.

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

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

Schema description coverage is 100%, and the schema itself documents every parameter including the nuanced provenance and confirm_untrusted_context fields. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

States a concrete verb (Send) and resource (message) plus the destination scope (channel or DM), so the agent knows exactly what the tool does. It does not differentiate itself from siblings such as slack_add_reaction or slack_get_thread, 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?

No when-to-use guidance, no exclusions, no mention of alternatives (e.g. using slack_add_reaction or slack_get_thread for reads). The agent must infer that this is the write path from the name alone.

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

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

Annotations already cover readOnly/idempotent/no-open-world, but the description adds real behavioral context beyond them: counts only, no message text, channel name, or user id recorded, and the receipt/hold state is process-scoped and therefore shared across all HTTP clients. These are privacy and scope facts an agent cannot get from 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?

Front-loaded with the core ('What this server process has actually done, as counts'), but the middle 'provenance label is a claim about one message; this is the claim about the whole session' is conceptual elaboration that lengthens the paragraph without adding call-time information.

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

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

With no output schema and no parameters, the description must explain what comes back, and it does enumerate the count categories plus the privacy limits. Adequate for a single-argless audit tool, though actual field names/shape remain unspecified.

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?

Zero parameters, so per the rubric the baseline is 4. The description correctly implies a no-argument call and adds no misleading parameter claims.

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

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

States a specific resource and scope ('what this server process has actually done, as counts') and enumerates the exact counts returned (messages read, outside-authored by origin, sends attempted, sends held). It is clearly the session-audit tool among the siblings, though it never names a sibling it differs from.

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

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

It gives a clear when-to-use: 'the only way to check after the fact whether outside-authored text reached the model and whether anything tried to send on the back of it.' No explicit exclusions or named alternatives, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint and idempotentHint true. The description adds meaningful context by listing exactly what is checked (health, age, auto-refresh, cache stats), enhancing transparency beyond annotations. No contradiction.

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

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

The description is a single, concise sentence that front-loads the key information. Every word earns its place, with no superfluous content.

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

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

Given the tool's simplicity (no params, no output schema, strong annotations), the description fully addresses what the tool does. It is complete for an agent to invoke correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to add parameter semantics as there are none.

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 specific verbs and resources: 'check token health, age, auto-refresh status, and cache stats'. It clearly distinguishes from sibling tools like slack_health_check (general health) and slack_refresh_tokens (token refresh).

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 (to check token status), but does not provide explicit when-not-to-use or alternatives. However, with zero parameters and a simple read-only purpose, the guidance is sufficient.

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

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

Annotations already state readOnlyHint, idempotentHint, and openWorldHint, so the description's lack of behavioral details is partly excused. The description adds no extra context beyond annotations, but does not contradict them.

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

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

The description is a single, concise sentence with no wasted words. It could be slightly more informative, but it is efficiently structured.

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 low complexity (1 param, no output schema, good annotations), the description is minimally adequate. However, it lacks information about what detailed information is returned (e.g., profile fields, presence), which would help an agent without an output schema.

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

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

Schema coverage is 100% (1 parameter with a brief description). The description adds no additional meaning beyond what the schema provides for 'user_id', so baseline of 3 is appropriate.

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

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

The description 'Get detailed information about a Slack user' has a clear verb ('Get') and resource ('detailed information about a Slack user'). However, it does not differentiate from siblings like 'slack_list_users' or 'slack_users_search', which also return user data.

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

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

The description provides no guidance on when to use this tool vs alternatives. It doesn't mention prerequisites (e.g., requiring a user ID) or when not to use it (e.g., for listing all users). Sibling tools exist for searching and listing, so this omission is significant.

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 idempotentHint. Description adds value by specifying case-insensitive partial match and the exact fields searched (name, display name, email). No contradictions.

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?

Single sentence with no waste. Efficiently conveys key 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 low complexity (two parameters, one required) and no output schema, the description is largely complete. It covers purpose, behavior, and input fields. However, it omits details about output structure or pagination behavior (e.g., limit parameter behavior).

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

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

Schema coverage is 100% and schema descriptions are thorough. Description's mention of searchable fields largely overlaps with schema description. Adds minimal new information beyond what schema already provides.

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?

Clearly states it searches workspace users by specific fields (name, display name, email) and describes the match behavior (case-insensitive partial match). Distinguishes from siblings like slack_list_users and slack_users_info.

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?

Clear context that this tool is for searching users by query, but does not explicitly contrast with alternatives or provide when-not-to-use guidance. Implicit from sibling names but not 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?

Beyond annotations (readOnlyHint, idempotentHint), the description adds the specific source file (~/.slack-mcp-workflows.json) and lists the return fields, providing operational context. No contradictions with annotations.

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

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

Two sentences with no waste: front-loaded with the main action, then filtering, then return fields. Every sentence adds value. Highly 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?

Given the tool's simplicity (list with one optional filter), the description fully covers purpose, source, return fields, and filtering. No output schema needed as fields are enumerated. Completeness for this tool is high.

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

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

Schema description coverage is 100% for the single parameter. The tool description reiterates the optional filter but does not add new meaning beyond the schema's description. Baseline 3 is appropriate.

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

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

The description clearly states 'List all saved workflow profiles from ~/.slack-mcp-workflows.json', specifying the action (list), resource (workflow profiles), and source (local file). It distinguishes from sibling slack_workflow_save which is for saving/updating workflows.

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

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

The description provides clear context for when to use this tool (to retrieve saved workflow profiles) but does not explicitly state when not to use it or compare with alternatives like slack_workflow_save. However, the purpose is obvious from the description.

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 idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds beyond that by disclosing the local storage path (~/.slack-mcp-workflows.json) and explaining that workflow_kind influences the output contract of slack_catch_me_up, which is additional behavioral context not present in annotations. No contradiction exists.

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

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

The description is exactly two sentences. The first sentence states the action and the bound elements; the second reveals storage and consumer linkage. Every phrase earns its place, and the most important action verb is front-loaded. No fluff or redundancy.

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

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

For a tool with 6 parameters, all documented in schema, and no output schema, the description is complete: it explains the purpose, storage, and how the saved profile is used by a sibling. It omits error handling and return values, but those are either covered by schema or not needed given annotations and the tool's nature. An agent can correctly decide when to call it and what to expect.

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

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

Although the schema covers all parameters at 100%, the description adds significant cross-tool semantics: it explains that summary_cadence sets slack_catch_me_up's default window (24h vs 7d) and that workflow_kind determines which output_contract keys are returned. This goes beyond the schema property descriptions, giving the agent a deeper understanding of how parameters affect downstream behavior.

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

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

The description states a specific verb ('Save or update') and resource ('workflow profile'), enumerates what the profile binds (workflow_kind, channels, priority people, retention mode, summary cadence), and lists the valid workflow_kind values. It clearly differentiates from siblings by noting that slack_catch_me_up reads the profile by name, positioning this tool as the write counterpart. No ambiguity remains.

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

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

The description provides clear context by explaining that the profile is stored locally and later consumed by slack_catch_me_up, implicitly establishing when to use this tool (to create/update profiles) vs. when to use the consumer. However, it does not explicitly state exclusions or alternative tools (e.g., 'use slack_workflows to list profiles'), so it stops short of fully explicit when-not guidance.

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