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

No annotations are provided, so the description carries the behavioral burden. It usefully discloses that scope data comes from Slack's x-oauth-scopes header and that nothing is sent to the workspace, making clear this is a safe read-style check; it does not cover error behavior or rate limits.

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

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

The description is compact and front-loaded: purpose first, then usage example, then behavioral note, then parameter clarification. Every sentence contributes useful information without repetition.

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. The description covers purpose, usage, data source, non-mutation, and the workspace parameter, but leaves minor gaps around how to obtain a valid workspace name and what happens if scopes are 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?

There is one required workspace parameter with 0% schema description coverage. The description clarifies it as a 'configured workspace name,' which adds some meaning beyond the bare schema field, but it does not explain the expected format or point to list_workspaces for discovery.

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: report the OAuth scopes a workspace token has and which tools it can use. This is a distinct diagnostic purpose, clearly separable from sibling tools like send_message, read_channel, and list_workspaces.

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 says when to call it: to confirm the Slack app was installed with scopes a feature needs, with a concrete example of checking files:write and im:write before using send_message with a file_path. It does not state when-not to use it or name alternative diagnostic tools, so it stops short of full routing 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?

With no annotations, the description carries the full burden and does well: it discloses the files.info resolution step, Bearer-token authentication, inline image downscaling, full-resolution disk saving, and the return path for non-image files. It stops short of covering overwrite behavior, error cases, or permission requirements.

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

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

The purpose is front-loaded in the first sentence, followed by useful behavioral detail and then compact parameter documentation. Every section earns its place given the low schema coverage.

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 side-effectful download tool with no annotations, the description covers the important behavior: authentication, image handling, disk writes, and returned paths. An output schema exists, so return values need not be fully specified, but overwrite and error behavior remain unstated.

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 Args section adds needed meaning. It clarifies file_id with an example format and source, and explains workspace as a configured workspace name, though workspace could be more precise.

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: downloading a Slack file by its file ID. It is immediately distinguishable from sibling tools such as search_messages or read_channel, none of which download files.

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 explains that file_id is the Slack file ID found in message file metadata and that workspace is a configured workspace name. This gives clear usage context, though it does not explicitly discuss when not to use the tool or name 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?

With no annotations, the description carries the safety profile well by emphasizing 'WITHOUT sending it' and explaining that it resolves and echoes the target. It does not mention auth requirements or rate limits, but for a preview-only tool the core behavioral distinction is clear.

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 preview/no-send behavior, then gives the when-to-use guidance, then compactly documents the three arguments. There is no wasted text.

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 preview tool with an output schema, the description covers purpose, safety behavior, usage, and parameter formats. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: workspace is a configured workspace name, channel accepts an ID or '#general'-style name, and text is Slack mrkdwn. This adds useful format semantics beyond the bare 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?

States a specific action and scope: preview a message without sending it, resolve the channel, and echo the target. It is clearly distinguishable from send_message and other 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?

Explicitly says to use this tool to review where a message would go before calling send_message. This names both the triggering context and the 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?

With no annotations, the description carries the full behavioral burden. 'Look up' implies a read-only retrieval, but the description does not state permissions, error behavior for unknown users or emails, ambiguity handling, or rate limits, so it gives only minimum viable context for a simple read.

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 definition is front-loaded with the lookup purpose and followed by a short Args block. It is compact, has no filler, and the identifier-format hints earn their 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?

This is a simple two-parameter lookup and an output schema exists, so return values do not need explanation. The description covers both inputs and their formats, but it leaves a small gap by not explaining how to obtain valid workspace names or when this tool should be chosen over related alternatives.

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 explains both required parameters, including that workspace is a configured workspace name and user is a U…/W… ID or email address. It could be slightly more precise about where workspace names come from, but it substantially covers the accepted input formats.

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: 'Look up a user' by Slack ID or email. It is clearly a single-user lookup, but it does not explicitly differentiate itself from siblings such as check_access or list_workspaces.

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 or when-not guidance and names no alternatives. An agent can infer that it retrieves a user, but it must guess when this is preferable to other user-related or access-checking 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 carries the behavioral burden. 'List' strongly implies a read-only operation and the filtering/limit semantics are disclosed, but permission requirements, rate limits, and pagination behavior are not addressed.

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 front-loaded with the core action and then gives compact parameter notes. Every sentence and argument line adds useful information without waste.

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. The description covers the purpose and all four parameters, but leaves some operational context unstated, such as permissions or what happens when more channels match than the limit.

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 defines all four parameters: workspace, name_filter case-insensitive substring semantics, allowed types values, and the 1-1000 limit range, though it omits the schema defaults.

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

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

States a specific verb and resource: list channels in a workspace, with optional name filtering. Clear enough to distinguish from list_workspaces and read_channel, though it does not explicitly route agents away from those 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?

The description implies when to use the tool by explaining optional filtering and type selection, but it gives no explicit when-not guidance or comparison to alternatives like read_channel or 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?

No annotations, but the description discloses the backing store (workspaces.toml), the payload shape (names + descriptions), and an important security trait ("Tokens are never returned"). It stops short of explicitly stating that the call is read-only or has no side effects, but 'list' plus the omission of tokens makes the safety profile clear enough.

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 purpose and the return fields front-loaded and the routing guidance immediately after. No filler, and every sentence carries information the schema does not.

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 a zero-param tool has no parameter gaps to fill. The description covers purpose, discovery role, and a security caveat, which is everything needed to call it correctly.

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

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

The schema has zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly adds that the output contains names and descriptions rather than any parameter detail.

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 the Slack workspaces") plus the source and the returned fields (names + descriptions). This is clearly distinguishable from every sibling, all of which operate inside a single workspace.

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?

"Call this first to discover the `workspace` values accepted by every other tool" gives an explicit when-to-use and explains the ordering relationship to all sibling tools. It also implicitly excludes other uses, so the agent does not have to infer 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?

With no annotations, the description must carry the disclosure burden. It usefully states newest-first ordering, the 1-200 limit range, and that oldest is inclusive — real behavioral data — but says nothing about pagination/cursors, required permissions, or whether the bot must be a channel member, which are critical for a channel-reading 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?

One-line purpose statement followed by a compact Args list — front-loaded and free of filler. The structure costs little and every line carries parameter 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 needn't be explained since an output schema exists, and all params are covered. Missing pieces are routing guidance against the three related sibling tools and any note on pagination, which matter for a 5-parameter history-read tool in this toolset.

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 fully documents all five parameters: channel ID formats (C…/G…/D…) vs '#name', limit as max messages newest-first, and Slack ts bounds with inclusivity. The only minor gap is not restating the limit default, which the schema already supplies.

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?

Clear verb+resource ('Read recent message history from a channel') with an added acceptance format for the channel identifier. However, it never distinguishes itself from sibling search_messages (which one would use for keyword queries) or read_thread (for reply threads), so an agent must infer the boundary.

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

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

Usage is implied by 'recent message history' plus the newest-first ordering, which suggests recency browsing rather than search. But there is no explicit when-to-use or when-not guidance and no mention of search_messages or read_thread as 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?

With no annotations, the description carries the full behavioral burden. It says it reads replies and gives a limit range, but does not disclose ordering, pagination behavior, permission requirements, or error behavior for invalid thread_ts.

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-loads the core purpose before the argument list. The Args format is efficient, though it reads more like a docstring than agent-facing guidance.

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. However, for a read tool with no annotations, the description lacks usage criteria and behavioral details such as reply ordering or pagination beyond the limit 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 compensate, and it does: it explains workspace as a configured name, channel formats (C/G/D IDs or '#general'), thread_ts as the parent message timestamp, and limit bounds (1-1000). Only the limit default of 200 is omitted.

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

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

The description states a clear verb and resource: read all replies in a thread. It distinguishes itself implicitly from read_channel, but does not explicitly differentiate from search_messages or explain when a thread read is preferable.

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

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

There is no guidance on when to use read_thread versus siblings like read_channel or search_messages. The description only lists arguments, leaving usage conditions entirely implied.

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. It does disclose useful behavior: Slack search operator support, the 1-100 count bound, and what the two sort modes mean. It omits the search's coverage (DM/private channel scope), permission requirements, and pagination/result-cap 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?

Front-loaded with the one-line purpose, then a compact args list that earns its place because the schema has zero descriptions. No filler sentences 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?

An output schema exists, so return-value explanation is not required, and parameters are fully covered. What's missing for a search tool with no annotations is scope and access context — whether results span DMs/private channels and whether the workspace must be pre-authorized via check_access.

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 all meaning must come from the description — and it documents all four parameters: workspace as a configured name, query with a concrete operator example, count as a 1-100 match cap, and sort's two values explained semantically ('score' = relevance, 'timestamp' = newest first). That is meaningfully more than the bare schema titles.

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

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

States a specific verb and resource ("Search messages") plus the scope ("across a workspace"), and notes Slack search operators are supported. That distinguishes it from the targeted-read siblings like read_channel and read_thread, though it never names them 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 rather than stated: the query example ('in:#general from:@alice variant calling') signals this is the tool for filtered/keyword retrieval across a workspace. There is no explicit guidance on when to prefer this over read_channel, read_thread, or list_channels, 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?

With no annotations, the description carries the full burden and does so: it discloses that confirm=False sends nothing and instead echoes back workspace, channel, text and attachments, explains the combined text+file comment behavior, and names the required OAuth scopes (files:write, im:write) with a pointer to check_access. That is unusually rich behavioral context 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?

The safety-critical constraint is front-loaded in the first line and the prose above the Args block adds real information. The Args list is long but earns its place given zero schema coverage; only minor redundancy remains between the prose and the parameter list.

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, and the description still explains what the preview payload contains. Combined with scope requirements, attachment semantics and threading, an agent has everything needed to call it correctly on the first try.

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 7 parameters, so the description must compensate and does — it documents accepted channel formats (C…/G…/D…, '#general', U…/W… for DMs), notes text is Slack mrkdwn and may be empty when file_path is set, and clarifies thread_ts, file_path and file_title defaults.

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

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

States a specific verb and resource ('Send a message to a channel') plus an immediate hard gate ('ONLY when confirm=True'). The confirm/preview mechanism makes it distinguishable from sibling draft_message without opening either 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?

Explicit two-step protocol: call with confirm=False to preview, then repeat with confirm=True to post, and it states the preconditions for attachments. It does not, however, contrast itself with the sibling draft_message, which is the nearest alternative for composing without sending.

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