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

No annotations are provided, so the description carries the full burden. The verb 'List' implies a read-only operation with no side effects, but the description does not explicitly state that it is non-destructive, nor does it mention authentication or rate limits. It is adequate for a listing tool but could be more explicit about side-effect guarantees.

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

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

The description is two sentences with no redundancy. The action and resource are stated first, followed by a precise usage instruction. Every word earns its place, and it is front-loaded with the core 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?

For a zero-parameter tool with no output schema, the description fully explains what the tool does and when to use it. It does not describe the exact return format, but the purpose of comparing local vs remote catalog is clear. An agent can invoke it correctly without additional context.

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 explain parameters, and it adds no parameter-related information beyond the schema, which is already complete (100% coverage with no parameters). This 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 states a specific verb ('List') and a clear resource ('local overlay tool names vs the current hosted mcp.slack.com catalog'). It is distinct from sibling tools like slack_stdio_reauth or slack_stdio_update_message, which perform different actions. The purpose is unambiguous.

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

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

The description explicitly says 'Use to verify the bridge is proxying the full remote set', providing a clear when-to-use context. It does not list exclusions or alternatives, but for a simple catalog-comparison tool this is sufficient. It clearly differentiates its use case from the other tool actions.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It identifies the endpoint but does not state that deletion is irreversible, what permissions are required, what happens to related data, or what the response looks like. For a destructive operation, this is a significant gap.

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 short and front-loaded with the core purpose. The first sentence is highly efficient; the second sentence provides rationale about hosted Slack MCP limitations, though its value is somewhat marginal.

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 two-parameter deletion tool, the description is minimally viable. However, with no annotations and no output schema, it omits behavioral details such as irreversibility, permission needs, and response/error behavior, leaving the agent with only partial context.

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 parameters are already well-documented. The description adds the 'user posted' constraint but does not add meaning to channel_id or message_ts beyond what the schema provides. It meets the baseline but adds little extra parameter value.

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

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

The description uses a clear verb ('Delete') with a specific resource ('a message the user posted') and names the underlying API method (chat.delete). It is distinguishable from sibling tools like update_message and remove_reaction without needing to inspect their 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?

The description implicitly scopes usage to messages the user themselves posted, which is a useful constraint. However, it does not explicitly state when to prefer this tool over alternatives or describe conditions where it should not be used, leaving some inference to the agent.

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

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

With no annotations provided, the description carries the full burden. It discloses that it writes bytes to disk, the default destination, the return fields (path, mime_type, size), the 50 MB limit, and the required permission. It does not detail error handling or behavior on exceeding max_bytes, but the core behavioral traits are clearly stated.

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 no filler. The purpose is front-loaded, the differentiation from slack_read_file comes second, and constraints/permissions close it out. Every sentence earns its place.

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

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

For a tool with no output schema, the description names the return values (path, mime_type, size). It covers when to use it, the default destination, the size limit, and the required scope. Missing are error cases and behavior when max_bytes is exceeded, but these are minor for a straightforward download 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 coverage is 100%, so the schema already documents all three parameters. The description adds the specific default directory name ('slack-stdio-mcp-downloads') beyond the schema's generic 'OS temp' and reiterates the 50 MB cap, but this is marginal extra value; the schema handles most semantics.

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

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

The description states a clear verb ('Download') and resource ('Slack file') plus the mechanism ('to disk by file_id'). It explicitly differentiates itself from slack_read_file by noting that the hosted tool 'often returns metadata-only for video or large binaries', giving an agent a precise reason to select this 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?

It names the alternative (slack_read_file) and the condition under which to choose this tool (when you need the actual bytes for video/large binaries). It also states a hard prerequisite ('Requires files:read') and a size constraint (Max 50 MB), leaving no ambiguity about when to call 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?

No annotations are present, so the description carries the full burden. It discloses that a browser opens, returns a URL, and optionally blocks until Allow or timeout. It also mentions retrying the previous tool. Missing details like timeout duration or failure handling are minor given the tool's simplicity.

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 logically structured from trigger to action to follow-up, with each sentence adding meaningful detail. It is slightly verbose but not wasteful, earning a solid score.

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

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

It covers when to call, what the tool does, what it returns, and the retry action. Since there is no output schema, the description explains the return value (clickable URL). Minor omissions like error handling do not significantly impact usability.

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 already describes wait. The description adds the 'or timeout' nuance and clarifies blocking behavior, which is extra value beyond the schema. This justifies a score above the baseline 3.

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

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

The description clearly identifies the tool as initiating Slack re-authorization, opens a browser, and returns a clickable URL. This distinguishes it from sibling tools that handle other Slack operations (catalog, messages, reactions), making the 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?

Explicitly states when to use: when a Slack session has expired and before any Slack action. It also instructs to retry the previous Slack tool after success, providing a clear trigger and follow-up, which effectively implies 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose that the tool removes a reaction the user added, implying it only works on reactions the user added, and it notes the emoji format. However, it does not disclose what happens if the reaction doesn't exist, whether it fails silently, or whether it requires specific permissions. For a simple mutation tool, this is adequate but not rich.

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

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

Three short sentences with zero waste. The core action is front-loaded, the API method is given for reference, and the emoji formatting note is placed at the end. Every sentence earns its place.

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

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

For a simple 3-parameter mutation tool with no output schema, the description covers the essential context: what it does, the API method, the catalog limitation, and the emoji format. It doesn't describe error behavior or permissions, but those are not critical for an agent to invoke the tool correctly. The description is complete enough for the tool's complexity.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds the emoji formatting rule ('without colons') and clarifies that channel_id can be a DM or IM id, which is already in the schema. The description adds marginal value beyond the 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?

The description states a specific verb ('remove'), a specific resource ('emoji reaction the user added'), and the underlying API method (reactions.remove). It also distinguishes itself from the hosted catalog, which only has add/get, making it clear this is the removal counterpart. This is a precise, unambiguous definition that an agent can act on without opening the schema.

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

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

The description explicitly notes that the hosted catalog only has add/get, implying this tool is the way to remove reactions. It also gives a formatting guideline for the emoji parameter. However, it does not explicitly state when to use this tool versus alternatives like update_message or delete_message, though those are clearly different operations. The context is clear enough for an agent to select it correctly.

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

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

No annotations are provided, so the description carries the full disclosure burden. It states the actions (list/cancel) but does not specify that cancel is permanently destructive or that list is read-only; nor does it mention permissions, rate limits, or side effects. While the actions are clear, the behavioral consequences are not fully disclosed, leaving meaningful gaps for an agent to infer.

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

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

The description is two succinct sentences with zero fluff. The first sentence names the two operations and the API methods, and the second compactly explains the parameter rules per action. Information is front-loaded, and every clause contributes to understanding how to use the tool.

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

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

For a simple tool with only three parameters and no output schema, the description covers all necessary input scenarios and even links a related tool limitation. What's missing are details about return values (e.g., list response format) and potential errors, which would round out the picture but are not critical given the tool's simplicity.

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

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

The schema already documents each parameter individually, but the description adds crucial relational semantics by grouping parameters by action: for list, channel_id is optional; for cancel, both channel_id and scheduled_message_id are required. This clarifies the parameter interplay beyond the schema's flat descriptions, making it easier for an agent to construct valid calls.

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 specific verbs ('List or cancel') with a concrete resource ('scheduled messages') and includes the underlying API method names, making the tool's function unambiguous. It also implicitly differentiates from siblings (e.g., delete_message, update_message) by name and by the explicit mention of scheduled messages, so no agent would confuse it with related 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 explicitly notes that 'Hosted slack_schedule_message cannot cancel,' which tells the agent when to choose this tool over its counterpart for cancellation. It also breaks down the two modes (list vs cancel) with their required parameters, providing clear usage context, though it doesn't mention scenarios where listing might be preferred over other tools.

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

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

No annotations are provided, so the description must carry the full burden of disclosing behavior. It states the output (re-auth progress and URL) but does not specify whether the tool is read-only, what happens when a session is valid, or any error conditions. The opening 'No Slack session' is misleading—it may be a static message rather than a reflection of tool behavior, and it does not clarify the tool's actual side effects.

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 short but not concise because the first sentence is an instruction to the agent ('Ask the user to authorize...') rather than a description of the tool. This waste of space confuses the reader and dilutes the actual functional description. The useful information is buried in the second sentence.

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 there is no output schema, the description must fully explain the return value and behavior. It only mentions reporting re-auth flow and a URL, but does not describe the full set of possible statuses (e.g., session valid, no session, re-auth in progress) or how they are encoded. An agent cannot reliably interpret the tool's result or handle all cases.

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 and schema coverage of 100% (empty schema), so the description does not need to explain parameter meaning. The baseline for no parameters is 4, and the description does not detract from this; it simply does not add anything beyond what the empty schema already implies.

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 name 'session_status' combined with the description's second sentence clearly states the tool reports whether a Slack re-auth flow is in progress and any authorize URL. This distinguishes it from action-oriented siblings like slack_stdio_reauth or update_message. However, the first sentence 'No Slack session. Ask the user to authorize Slack...' is ambiguous—it reads as a directive rather than a neutral description, muddying the purpose.

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

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

There is no explicit guidance on when to call this tool versus alternatives. The sentence 'Ask the user to authorize Slack before any Slack action, then retry' implies a precondition check, but does not explicitly state 'use this tool to check if a session exists before invoking other Slack tools.' It also does not mention the sibling slack_stdio_reauth as a fallback or differentiate when to use reauth.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the edit scope ('message the user posted') and names the API, but it does not mention permissions, reversibility, error behavior, or what happens when the message_ts is invalid. This is a moderate gap for a mutation tool.

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

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

Two short sentences with no filler. The core purpose is front-loaded, followed by the API name and required parameters. Every sentence earns its place.

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

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

For a simple three-parameter edit tool, the description covers purpose, the key limitation, and all required inputs. There is no output schema, but a successful edit's return shape is not critical for invoking the tool correctly. Slightly more detail on failure conditions would make it complete.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds only a restatement: it names channel_id, message_ts, and 'new message text', and clarifies that message is replacement text. This is baseline-adequate but adds little 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 opens with a specific verb and resource: 'Edit a message the user posted', and names the underlying API (chat.update). This clearly distinguishes it from sibling tools like delete_message and remove_reaction, which are different operations.

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

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

The description explicitly notes that 'Hosted Slack MCP can send but not edit', which tells the agent when this custom tool is the right choice. It also lists the required identifiers. It could be stronger by stating when delete_message would be preferred, but the context is sufficiently clear.

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