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

With no annotations provided, the description carries the full burden and delivers: it says the operation is a read, accepts names or IDs, mentions name lookup caching, notes that only top-level messages are returned, and discloses cost implications (resolve_names costs one call per user). This is rich behavioral transparency.

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 well-structured: a one-line purpose, then a short behavior note, then a compact Args list. Every sentence adds value, with no fluff, making it easy to scan and 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 tool with 6 parameters and no annotations, the description covers all invocation concerns: params, defaults, behavior, limitations, and an alternative tool. Since an output schema exists, not describing the return format is acceptable. The description is complete.

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

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

Schema description coverage is 0%, but the Args section fully explains every parameter: channel accepts name or ID, oldest/latest accept multiple date formats and semantics, limit has a default, resolve_names has a cost note, and include_broadcasts filters broadcast messages. This fully compensates for the lack of schema descriptions.

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 starts with 'Read messages from one channel over a time window,' giving a specific verb, resource, and scope. It also distinguishes itself from sibling tools by explicitly directing users to slack_thread for expanding replies, making its purpose clear.

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

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

It clearly states when to use this tool ('Read messages from one channel over a time window') and provides an explicit alternative: 'use slack_thread to expand any message whose reply_count is non-zero.' This helps the agent choose between 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?

With no annotations provided, the description must disclose behavioral traits on its own, and it does well. It explicitly mentions that 'Replies are attached to their parent message rather than returned flat,' and it warns about the throttling risk of enumerating an entire Enterprise Grid workspace. It also reveals the deliberate limitation that pattern discovery only sees joined channels. This goes beyond basic schema info, though it doesn't cover every edge case like pagination or timezone handling.

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 well-structured and front-loaded with a one-sentence summary, followed by a brief usage note, a warning about pattern limitations, and a clean args list. Every section earns its place. The argument list is compact yet informative, using inline formatting to keep each entry scannable. There is 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 7 parameters and an output schema, the description covers the essential aspects: purpose, usage modes, a key limitation (pattern discovery on joined channels only), and parameter semantics. Since an output schema exists, return-value details are not needed. Minor gaps remain, such as behavior when neither channels nor pattern is provided, or what happens with invalid date formats, but these are not critical for the core operation. Overall significantly above 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?

The schema has 0% description coverage, so the description carries the full burden for parameter meaning. It excels: every parameter is explained with format (e.g., oldest as 'YYYY-MM-DD', epoch, or offset like '-7d'), defaults (latest 'Defaults to now'), mutual exclusivity (channels vs pattern), and side effects (min_members 'Costs one extra (cached) API call per matching channel'). This provides far more than the bare schema properties.

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 first sentence clearly states the tool's function: 'History for several channels over one time range, threads nested inline.' This uses a specific verb (history) and resource (several channels), and the threading note distinguishes it from flat message lists. The sibling tool slack_channel_history is implied as the single-channel counterpart, and slack_dm_history covers DMs, so the multi-channel scope is well differentiated.

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

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

The description provides clear usage context: it explains the two mutually exclusive selectors (channels list vs pattern) and gives guidance on pattern limitations ('only sees channels you have joined'). It also notes the cost of min_members. However, it doesn't explicitly name alternative tools like slack_channel_history for single-channel needs or slack_search for search scenarios, leaving some inference to the agent. The context is clear but not exhaustive in exclusions.

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

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

No annotations are provided, so the description carries the burden. The verb 'Read' implies a non-mutating operation, and the parameter descriptions add some semantic context (e.g., 'Resolve user IDs to display names'). However, there is no disclosure of potential side effects, permissions, rate limits, or pagination behavior. 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?

The description is concise, front-loaded with the purpose, and uses a clean Args format. Every sentence adds value with no redundancy or fluff.

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. Parameters and purpose are well covered. The only gap is the lack of guidance on when to use this versus sibling tools, but overall the description is complete enough for a read-only DM history tool.

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

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

Schema description coverage is 0%, but the description thoroughly defines all four parameters: user (username, @username, or ID), limit (default 50), oldest (date or epoch), and resolve_names (boolean effect). This fully compensates for the missing schema descriptions.

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

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

The description uses a specific verb and resource: 'Read direct-message history with one person.' This clearly distinguishes it from sibling tools like slack_channel_history (channel history) and slack_thread (threads), making the tool's 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?

The tool's context is clear: it is for direct-message history with a single user. However, it does not explicitly state when not to use it or mention alternatives from the sibling list (e.g., slack_search), so it lacks explicit exclusions.

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

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

With no annotations, the description carries full behavioral disclosure. It reveals that the tool enumerates conversations.list, is expensive, may return a rate_limited error on large workspaces, and notes that include_private only includes private channels the user has joined. This is strong, actionable transparency beyond the input 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?

The description is well-structured: a one-line purpose, a highly relevant cost warning, explicit alternatives, and a compact Args list. Every sentence earns its place, and the most important usage caveats are front-loaded.

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

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

Given the tool has no required parameters and an output schema exists, the description covers all necessary context: purpose, filtering parameters, cost/rate-limit behavior, and recommended alternatives. It is fully sufficient for an agent to decide when and how to invoke the 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?

The input schema has no per-parameter descriptions, but the description provides a clear Args section explaining pattern (fnmatch glob), min_members (minimum member count), include_private (joined private channels), and limit (maximum channels returned, default 200). This fully compensates for the schema's lack of descriptions.

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 ('Discover') and resource ('channels') and clearly states the filtering criteria (glob pattern and minimum member count). It also distinguishes this tool from siblings by noting when alternative tools are preferable, 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?

The description provides explicit when-to-use guidance: it warns that this tool is expensive and rate-limited, and explicitly says to skip it and use slack_channel_history when the channel name is already known, and to use slack_channels_history for globs over joined channels. This directly helps the agent choose among siblings.

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

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

With no annotations provided, the description takes full responsibility for behavioral disclosure. It reveals that the tool is disabled by default, requires a specific environment variable, refuses to execute without it, and explicitly states that 'no agent action can post by accident.' It also clarifies the identity aspect ('as yourself'), which is important for a mutating operation. This goes well beyond the bare minimum.

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 well-structured: a one-line purpose, a short safety warning, and a clean argument list. Each sentence earns its place—no redundancy, no fluff—while still covering all critical 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?

For a write tool, the description covers purpose, safety gating, identity, and parameter semantics thoroughly. It does not discuss rate limits or explicit alternatives, but the presence of an output schema handles return-value documentation, and the sibling names make its unique role clear. Slightly more could be said about when to choose this over other tools, but it is largely 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?

Although the schema has 0% description coverage, the description's 'Args:' section adds substantial meaning: channel is 'name or ID', text is 'Message body (Slack mrkdwn)', and thread_ts is an 'Optional thread parent timestamp, to reply in-thread.' This goes far beyond the schema's minimal type and title information.

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 'Post a message to Slack as yourself,' which uses a specific verb and resource, immediately distinguishing it from sibling read-only tools like slack_search and slack_channel_history. The purpose is unambiguous and sets the tool apart clearly.

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 usage context by stating it is 'DISABLED by default' and requires 'SLACK_MCP_ALLOW_WRITE=1', indicating when the tool can be used. It does not explicitly name alternative tools or state when-not-to-use cases, but the sibling list is entirely read-oriented, making the write-tool distinction obvious.

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 discloses key behaviors: resolves custom fields to labels, rewrites user-typed fields from IDs to display names, returns field_definitions alongside profiles, and gracefully handles unresolvable entries with error objects. It does not mention authentication or rate limits, but for a read-only lookup tool, the provided transparency is solid.

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 concise and well-structured, with a clear opening statement, a helpful comparison, and a dedicated Args section. Each sentence adds value, though the comparison could be slightly more compact without losing essential 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?

Given the tool has one parameter, an output schema, and no annotations, the description is complete. It covers purpose, usage, behavioral details, argument format, and error handling. No important context is missing.

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

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

The input schema only defines 'handles' as an array of strings, but the description enriches it by specifying accepted formats ('Usernames, @usernames, or user IDs') and documenting error handling for unresolvable entries. This fully compensates for the 0% schema coverage.

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

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

The description clearly states the function: 'Look up full profiles for several people at once.' It distinguishes itself from slack_user by explaining it is 'Richer than slack_user' and resolving custom fields and user-typed fields from IDs to labels, making the purpose distinct and specific.

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 provides usage guidance: 'Use slack_user for a quick single ID-to-name lookup; use this to populate records for several people.' This clearly states when to use this tool versus the alternative slack_user.

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 explains supported operators, default count, sort semantics, and the effect of include_broadcasts=False, which goes beyond basic operation. It does not mention rate limits or authentication, but for a read-only search tool it provides substantial transparency.

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 well-structured and front-loaded, opening with a clear purpose then giving operator examples, then an Args block with each parameter's meaning. Every sentence earns its place, including the practical query example, and the length is appropriate for the tool's complexity.

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 moderate complexity (4 parameters, 1 required), an output schema exists, and the description covers usage context, parameter semantics, and behavior. It is complete enough for an agent to select and invoke the tool correctly without additional information.

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 does so thoroughly: it explains the query format with concrete examples, defines count default, clarifies sort values ('timestamp' vs 'score'), and specifies the behavior of include_broadcasts. This adds significant meaning beyond the bare input 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 tool searches Slack messages using native Slack search syntax, with a specific verb and resource. It explicitly notes it is the 'widest net' for workspace-wide questions, distinguishing it from channel/history-specific sibling tools like slack_channel_history and slack_dm_history.

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 provides clear context for when to use the tool: for 'where was X discussed' questions across the whole workspace. It does not explicitly name alternative tools or say when not to use it, but the 'widest net' phrasing and operator examples imply its broad-search role relative to the narrower sibling 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 burden. It discloses that the tool returns both the parent message and all replies, and explains how limit and resolve_names work. However, it does not mention rate limits, auth needs, pagination behavior, or edge cases like invalid thread_ts, which would be useful.

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 concise, front-loaded with the main purpose, and each argument is explained in one line. No redundant fluff.

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

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

The tool has an output schema, so return values are likely covered there. The description covers purpose and parameters adequately. It lacks explicit guidance on alternatives and edge cases, but for a simple fetch tool, it is fairly 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?

With 0% schema description coverage, the description's argument explanations add valuable meaning. For example, it clarifies that thread_ts is the timestamp of the thread parent and can come from a previous result's ts field. This goes beyond the schema's simple 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?

The description clearly states the tool's function with a specific verb ('Fetch') and resource ('every reply in a thread, including the parent message'). This distinguishes it from sibling tools that handle channel or DM history, as it is specifically for thread replies.

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 the tool is for fetching thread replies but does not explicitly compare it to siblings like slack_channel_history or slack_search. There is no mention of when to use this over alternatives or any exclusions, so usage guidance is only 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 provided, the description must carry the full behavioral transparency burden. It discloses one side effect—'include_custom_fields... costs one extra API call'—which is valuable. However, it does not mention whether the operation is read-only, require any special permissions, or how it handles invalid identifiers or missing profiles, leaving gaps in the behavioral picture.

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 cleanly structured: a one-sentence purpose, a brief 'Use this to' paragraph, and a two-item Args list. Every sentence adds value, there is no redundant jargon, and the most important information is front-loaded. It is concise without being under-specified.

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 fairly simple lookup tool with only two parameters and an output schema present, the description covers purpose, usage, and parameter semantics well. It omits minor details like error behavior or case sensitivity, but overall it provides enough context for an agent to correctly select and call the tool, especially with the existing 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?

The input schema has no descriptions for its parameters (0% coverage), so the description is the sole source of parameter meaning. It fully compensates by explaining name_or_id accepts 'Username, @username, display name, or user ID' and describing include_custom_fields as resolving custom profile fields to labels with an extra API call cost. This goes well beyond the schema's bare property names.

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 'Resolve a username or user ID to a profile,' which precisely states the action (resolve) and resource (profile). It also provides concrete use cases (converting raw user IDs to names, looking up title/timezone/custom fields), clearly distinguishing it from sibling tools like slack_search or slack_channel_history which focus on different resources or actions.

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 this to turn a raw user ID from another result...' and outlines specific scenarios, giving clear context for when to invoke the tool. It does not name alternatives or state when not to use it, but the usage context is strong enough to guide an agent without confusion.

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 fully discloses behavior: searches both from and to the user, optionally includes surrounding channel history, optionally expands threads, deduplicates, and returns nested replies plus a stats block. This goes beyond a simple verb phrase and provides actionable context about how the tool operates.

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 well-structured: a concise opening statement, a short usage rationale, and a clear parameter list. Every sentence adds value; no fluff or repetition. It is appropriately sized for a tool with 6 optional parameters and complex behavior.

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 complexity, the description covers purpose, usage, behavior, cost, and parameters thoroughly. The output schema is present, so return values need not be described. This description is fully complete for an AI agent to select and invoke the tool 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 descriptions, so the description carries full weight. The Args section explains each of the 6 parameters with formats, defaults, and behavioral implications (e.g., 'context_window: Seconds of surrounding channel history... 0 fetches no context'). This is far richer than the bare schema and gives the agent all needed parameter 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 opens with a clear, specific verb phrase: 'Everything one person said or received in a time range, grouped by channel.' It explicitly distinguishes itself from siblings by stating 'Prefer this over assembling the same result from slack_search plus slack_channel_history plus slack_thread,' making the tool's unique role immediately obvious.

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

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

Provides explicit usage guidance: 'Prefer this over...' and explains why (deduplicates across passes). Also gives a practical constraint: 'Cost scales with the number of channels the user was active in.' This helps the agent decide when this tool is the right choice.

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